3.5.0-rc.1 LED Issuse

danzaywer

@gloomyandy It worked on 3.4.6, could not try downgrade at the moment, too many changes to do

droftarts

@danzaywer I’ll test later. The LEDs I have all work on 5V and 3.3V signalling on Duet 3 (except if I use them on an io.in pin), but the first LED (of 7) doesn’t respond correctly on Duet 2, and the string goes full on on Maestro whatever I send (which hasn’t supported Neopixels before 3.5). So it does feel like something is not quite right.

Ian

droftarts

@danzaywer @gloomyandy Okay, I just tried my LEDs on 3.4.6, and sure enough, they all work. So there is definitely a difference between 3.4.6 and 3.5.0-rc.1. I'll report it to @dc42.

Ian

danzaywer

@droftarts Ok, thanks for checking

gloomyandy

@droftarts Was the setup you used using bit-banging or hardware output?

droftarts

@gloomyandy I’m not sure. This was using CONNLCD pin 5 on a Duet 2 WiFi (board is actually a pre production white PCB, but I don’t think that matters). In 3.4.6 I tried to set M150 X1 (the default) but I got a message about ‘unsupported LED type’, I didn’t set any other LED type, but then it worked anyway. I think frequency was set at 2500000Hz.

On 3.5.0-rc.1 I set M950 E0 T1 Q3000000. I don’t know if that means they are bit-banged.

The LEDs are a string of 7 SK6812 4020 RGB sidelight LEDs, from https://coolcomponents.co.uk/products/led-side-light-strip-white-1m-adafruit-neopixel-compatible?_pos=1&_sid=e9f065ecd&_ss=r

I can retest later, and I’ll post the code and responses. Let me know if there’s anything else you need.

Ian

gloomyandy

@droftarts A good way to check is to run M950 E0, that should report if it is using bit-bang or not (on 3.5 at least). It is probably best not to set a frequency with the Q option and just use the default (at least to begin with). I think that way you will be testing like with like between the two versions.

droftarts

@gloomyandy Managed a quick test. Looks like bit-banging is used in both RRF versions. Also, it seems the default for Duet 2 is 2.5MHz.
3.5.0-rc.1:

M950 E0 C"connlcd.5" T1
M950 E0
NeoPixel_RGB strip on port "(connlcd.np,connlcd.db7,connlcd.5)" uses bit-banging, frequency 2500000Hz, max strip length 60
M150 R1 S7   ; first LED turns on green 255, the rest dimly red
M150 r255 S7 ; first LED turns yellow (green 255 red 255), the rest red 
M150 r0 S7   ; first LED stays green 255, the rest off

Whatever I send, the first LED stays green 255, with other colours mixed in if set, while the other LEDs respond correctly. Changing frequency made no difference.

3.4.6:

M150
Led type is NeoPixel RGB bit-banged, frequency 2.50MHz
M150 R1 S7   ; All LEDs turn on dimly red
M150 R255 S7 ; All LEDs turn on full red
M150 R0 S7   ; All LEDs turn off

All subsequent commands, whatever the colour mix, also respond correctly. Changing frequency made no difference. If I tried to set M150 X1 or M150 X3 in RRF 3.4.6, I'd get Error: M150: Unsupported LED strip type.

I also tried a short string of 3x 5050 SK6812 RGBW LEDs. Once I'd remembered to switch from RGB to RGBW (M950 T2 in RRF 3.5.0-rc.1, and M150 X4 in RRF 3.4.6), I had exactly the same behaviour; in 3.5.0-rc.1 the first LED always had green 255 once any value was set, whereas in 3.4.6 it behaved correctly.

Let me know if you want me to do any more test.

Ian

danzaywer

@droftarts I have the same behavior, I have RGBW LEDs, set with M950 E1 C"duex.pwm5" T2

DonStauffer

@danzaywer Just upgraded my Duet 2 WiFi to 3.5 RC3 and my first LED now stays lit green no matter what I do. So this seems to be a common problem with this firmware version, I guess. I'd be interested to know what to do. Q800000 didn't work for me, nor has anything else I've tried.

In 3.4.0 this worked fine in config.g:

M950 E0 C"connlcd.np" T1 ; NeoPixel RGB
M150 E0 R0 U0 B0 P0 S10 F0 ; Off

All LEDs went dark, as intended, then M150 commands worked fine.

droftarts

@Ce72 @danzaywer @RYANPDX This issue has been fixed. Latest binaries are here: https://www.dropbox.com/scl/fo/wrp6hvr39vjxjlep89p5x/h?rlkey=hzka49sxnsqjpwsvy46m26ms0&dl=0

Ian