3.5.0-rc.1 LED Issuse

gloomyandy

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

danzaywer

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....

gloomyandy

@danzaywer If you go back to an older version of the firmware (which version did you have?), does it work?

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.