3.5.0-rc.1 LED Issuse
-
Hi
I'm using the 6HC mainboard in SBC mode on 3.5.0-rc.1, and I have a Neopixel led strip with 31 LEDs connected to the LED header on the board. When I first power on the machine the LEDs all work fine. However after a short period of time or after running a print, only the first 10 LEDs respond to any commands and the others stay on what they were first set too. so far the only way I have found to clear the issue is to power cycle the whole machine, restarting the mainboard does nothing to help.Is this a software bug or is there somthing I'm missing
-
@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
-
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 -
@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 U144I'll be getting some of my own RGBW LEDs to test soon.
Ian
-
@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
-
@RYANPDX Did you change the data rate as well, or did you leave that at 3Mhz?
Ian
-
@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
-
@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
-
-
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 S3the first remains green, with
M150 E0 R255 U0 B0 S3the first is orange (red + green) the other two red, with
M150 E0 R0 U0 B0 W250 S3the 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.
-
@danzaywer Can you post your M950 command showing how you define the pin used to access the pixels.
-
@gloomyandy Certainly
M950 E0 C"connlcd.5" U3 T2 -
@danzaywer Can you try running M950 E0 in the console and post the output here.
-
M950 E0 NeoPixel_RGBW strip on port "(connlcd.np,connlcd.db7,connlcd.5)" uses bit-banging, frequency 2500000Hz, max strip length 3 -
@danzaywer default frequency should be 3000000Hz ?
-
@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.
-
@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
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
@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? onM950 E1 C"duex.pwm5" T2is same same .
-
@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
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
@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.
