3.5.0-rc.1 LED Issuse

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

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?