WS2812B LED strip control addressing issue?

SuperLongBoard ❓Question
1

Hi team-

I’m continuing my journey to get a SLB working, and today managed to spend some time on a WS2812B LED strip plugged into the RING light port. (FWIW, the first two strips linked from the SLB Technical Manual now 404 on Amazon.ca…) It seems to me that a WS2812B should behave the same as a WS2812, but please correct me if this isn’t the case.

I’m using a 30 LED strip for now, but noticed that only the first 4 of the LEDs track the status color of the SLB, the rest remain white.

30 LEDs of jogging (ish)
30 LEDs of jogging (ish)1920×1921 328 KB

If I change the $664 parameter to 8, only 8 of the 30 LEDs light up as expected, so it does seem like some aspect of the LED addressing is working correctly. In this configuration, only the first 1.5 LEDs follow the status color (it looks like the 2nd is maybe getting two of the three RGB channels worth of data or something?), the rest similarly remain white. Running M356 P1 Q2 to turn the ring lights off turns off all channels of LED 1, but only red & blue channels of LED 2. The remaining 6 LEDs are on full white. Changing to any other value in $664 will power up that number of LEDs, with some other variation of how many might actually respond to the status color.

8 LEDs of jogging (ish)
8 LEDs of jogging (ish)1920×1921 159 KB

I had a quick skim through the neopixel code in the grblHAL source, but didn’t see anything that immediately jumped out at me as an issue aside from a weird special-casing of neopixel1_out vs neopixels1_write.

Also the strip seems to be in a fairly non-sensical state prior to homing completing, only lighting up the first few LEDs. The first LED tends to reflect the machine state (RED) when it is alarmed coming up and then the first LED changes to BLUE during homing, the rest are gibberish. It is not clear to me what this is intended to indicate.

Has anyone else gotten this to work as expected? It sort of seems to work if I only enable 1 LED, maybe because of neopixel1_out instead of neopixel1_write?

Please let me know if this is better filed against grblHAL.

Thanks for considering!

2

Well this appears to be a cable length issue. Somewhere between 100mm 5m and 9m of cable this appears to stop working reliably. At 5m of cable this does reach through all of the drag chains on a 4ft x 4ft table and work ok. That’s what I get for testing with the rest of the length of cable I was using not cut down yet.

It looks like the grblHAL code has some ability to change the brightness of the LEDs; would it be possible to expose this to gcode or a firmware setting? These 5050 packages are obnoxiously bright without some sort of diffuser.

1000006147
10000061471920×1921 214 KB

1000006149
10000061491920×1921 369 KB

1 Like
3

The LED brightness is definitely something to be remedied in a future firmware version :+1: Curious thing about the cable length, though I’ve never tried excess lengths I’ve not seen issues when we’ve done testing for our many different-sized machines, good to note though I think I’ll add it into our docs

EDIT: man I hate 404’d pages

1 Like
4

By the way if this is interesting to you at all, our resources are all available to be edited by anyone via Git, so if you see anything you’d like changed I’m always open to contributions :smiley:

1 Like
5

Thanks @chrismakesstuff. I may have a go at a setting to change the CCT of the “white” status as well, the weird 7000K-ish white that gets made by default is kind of unpleasant in my ~3500K workshop.

At some point I’ll probably bother you about getting the webbuilder for grblHAL to work for the SLB so I can start contributing (per your notes about the github docs as well).