3.5.0-rc.1 LED Issuse

[droftarts]

@Ce72 please post you config.g or how you are configuring them, and the code you’re using to change the LEDs. Please show the wiring for the LEDs too.

Ian

[RYANPDX]

I am also seeing strange behavior on 3.5 RE: Neopixel LEDs.

Only about half the strip is lighting, and it doesn't seem like there is any way to get the second half lighting. We are running 144 LEDs and way more than just 10 are lighting. I would say about half without counting up all 144.

Previously on 3.3 and 3.4 - using a standard 5v NeoPixel LED strip wired to the DOTSTAR header DO & Ground pins, we just sent the commands and everything worked. No hardware or wiring changes.

Here was the working code from 3.3/3.4 - and the updated code for 3.5.

3.3/3.4

Command: M150 R255 U255 B255 S144

3.5.0-rc.1

Config.g: M950 E0 C"led" T1 Q3000000
Command: M150 R255 U255 B255 P255 S144 F0

[droftarts]

@RYANPDX See the notes for M950:

Unnn (optional) The maximum number of LEDs in the strip. Default 60, larger values use more memory.

The default maximum number of LEDs in a strip is 60. It can be increased using the M950 U parameter, subject to
(a) available RAM and
(b) on the 6HC and 6XD there is an additional limit because the DMA buffer has to be in non-cached memory. For 6HC and 6XD the max LEDs for a strip connected to the dedicated LED port is currently 240 Neopixel RGBW or 320 RGB. It might reduce in future.

When configuring a LED stirp on a tool board or 1XD, using a lower U parameter (ie set U to the number of LEDs) is advised to save RAM, because there is very little free RAM on those boards.

Also check what LED controller your LEDs are using; the datasheets for SK6812 and WS2812B LEDs that I have seen suggest a data rate of 800Kbps, though clearly you're making it work with a much higher data rate at the moment.

So try setting M950 to:

M950 E0 C"led" T1 Q800000 U144

I'll be getting some of my own RGBW LEDs to test soon.

Ian

[RYANPDX]

@droftarts my brain skipped past the U option probably 20 times over the past couple days. That 100% solved the issue! Sorry to confuse the OP with an unrelated issue, I was just trying to keep it clean and grouped with similar issue.

I've got full control over 144 LEDs

[droftarts]

@RYANPDX Did you change the data rate as well, or did you leave that at 3Mhz?

Ian

[RYANPDX]

@droftarts reduced the data rate as well per your advice. Thank you so much!

FYI I picked up the default from: https://docs.duet3d.com/en/User_manual/Connecting_hardware/IO_Neopixel_DotStar

[droftarts]

@RYANPDX Yes, it's in M150 as an example, too. I'll check with @dc42 because it's not clear if the Q parameter sets the data rate (in bits per second) or the SPI frequency (in Hz), or if they are actually the same anyway!

If Q800000 is working for you, though, I'll take that as a good sign, and it might help @Ce72 .

Ian

[droftarts]

@RYANPDX my mistake! According to @dc42 ” The SPI clock frequency is 4x the bit rate” so 3KHz (or even 3.2KHz) should be fine. Lower rates will take longer to update the LEDs, and might be noticeable on long LED strings. I’ll update the documentation.

Ian

[danzaywer]

I have a strange behavior on the leds with the 3.5rc1 too, on duet2 wifi . Basically, the first set is successful if done at the same time as the print starts (I have the M80 command in the start.g and M150 R255 S3) after which with any other M150 the green on the first LED remains lit as a residue. For example, with

M150 E0 R0 U0 B0 S3

the first remains green, with

M150 E0 R255 U0 B0 S3

the first is orange (red + green) the other two red, with

M150 E0 R0 U0 B0 W250 S3

the first green, the other 2 white. I have 3 neopixel rgbw leds for the stealthburner, port CONN_LCD and a 74HCT08, older firmware all worked. I also wired 3 other LEDs to another connector with 5V logic of the Duex5, without 74HCT08, and configured E1 strip but the behavior is the same. If power on outside print and send an M150 the issue is present at first shot.

[gloomyandy]

@danzaywer Can you post your M950 command showing how you define the pin used to access the pixels.

[danzaywer]

@gloomyandy Certainly

M950 E0 C"connlcd.5" U3 T2

[gloomyandy]

@danzaywer Can you try running M950 E0 in the console and post the output here.

[danzaywer]

@gloomyandy

M950 E0
NeoPixel_RGBW strip on port "(connlcd.np,connlcd.db7,connlcd.5)" uses bit-banging, frequency 2500000Hz, max strip length 3

[danzaywer]

@danzaywer default frequency should be 3000000Hz ?

[gloomyandy]

@danzaywer I'd try different frequencies from 2000000 up to say 3200000. I've found that different pixels sometimes need the frequency to be adjusted a little. You should be able to change the settings (and set the pixels) from the console to try out different configurations.

[droftarts]

@danzaywer Are you definitely getting a 5V signal on the data line to the first LED? I've been playing around with LEDs for the last couple of days on a variety of Duet boards, and have a similar effect when controlling them from 3.3V pins.

Ian

[danzaywer]

@gloomyandy Nope
I try from 3200000 to 2000000, also 1600000 and 8000, 800 500 just to try, green is always on everytime i send an M150. Maybe an hardware foult of my duet? on

M950 E1 C"duex.pwm5" T2

is same same .

[droftarts]

@danzaywer And it worked okay in older firmware? What version? If so, I doubt it's a hardware fault. Maybe, just maybe ... a ... firmware ... bug!?

Ian

[danzaywer]

@droftarts On duex.pwm5 I should have 5v from external source, I have atx 5v rail connected on "EXT 5v" and "5v AUX" jumper is on "5v ext", while the strip on CONN_LCD have signal on a 74HCT08.

[danzaywer]

@droftarts Yes, it worked fine. BTW no a great issue, if set blue I have cyan....