Issues with 45+ LED Neopixel chain

General Discussion
1

Basic Information:

Printer Model: Ender 3
MCU / Printerboard: BIGTREETECH SKR MINI E3 V2
klippy.log

klippy.log (247.1 KB)

Describe your issue:

I have a 62 Neopixels in a chain and is being provided external power with shared ground.
When the printer starts up the LEDs all correctly light up based on the initial_COLOR [neopixel] settings.

Problems start when using SET_LED.

The last 0-20 LEDs do not always change to their correct state. The bug can be replicated but the outcome is not always the same, the number of LEDs not changing state is not always the same.
In some cases the last 10-15 LEDs seem to glitch and change in a group rather than one by one (this is best seen in the videos at the end).

I had to add the rest of this post as separate replies due to the new user limits.

2

Example Red:
SET_LED led=neo red=0.1 green=0.0 blue=0.0 transmit=1

This should set all LEDs to red at once to red, in my case the test I did while writing this left 16 pixels not red.

image
image838×1098 103 KB

3

Example Green:
SET_LED led=neo red=0.0 green=0.1 blue=0.0 transmit=1

This one worked.

image
image822×1091 107 KB

4

However after switching to some other colours and back to green I had 12 missing updates.

image
image735×904 83.9 KB

5

I have a few test macros since I have been trying to debug this myself.
First is ‘led_test_bug’ which loops through all 62 LEDs and immediatly sets the colour which gives the effect of a growing rainbow.
The second ‘led_test_bug2’ loops through a few colours for the whole chain at once.
Since macros are in the log I won’t include them here.

Rather than write out in loads of words I recorded a few videos showing the issues.

Shows the LEDs ‘glitching’ near the end and missing 5 LED updates.

LEDs changing colours at the same time for the chain showing missing LED updates

6

LEDs changing colours at the same time for the chain showing missing LED updates also close up of ‘glitching’**

Shows state of LEDs updating near the end of the chain to what they should be when the macro is updating LEDs to a different state at the beginning

7

I am not the only person to have this issue since recently a user posted:

And in Discord

8

If you look at the log that you posted you’ll see many Neopixel update did not succeed warning messages.

The neopixel transmit messages require very tight timing, and the longer the led chain, the harder it is to get good timing.

Many of the newer neopixels don’t need as strict timing as some of the older neopixels. Some users have reported success in altering the timing constants (eg, neopixel: increase BIT_MAX_TIME to increase compatibility on AVR by ayufan · Pull Request #4525 · Klipper3d/klipper · GitHub ).

If you want to try the above, modify the klippy/extras/neopixel.py file and increase the BIT_MAX_TIME parameter to .000030. After any change to the source code you must run a full sudo service klipper restart for that change to take effect.

-Kevin

1 Like
9

Thanks Kevin this has worked perfectly.

I was experimenting with the firmware side and did get much more reliable behaviour by commenting out the following in src/neopixel.c

if (neopixel_check_elapsed(last_start, start, bit_max_ticks))
goto fail;

Your solution resolves the error rather than mine just hiding it!

Is this something that could make its way into the main branch to avoid others having the same issue? I appreciate you may not want to break old neopixel setups but maybe exposing this setting in the printer.cfg and documentation may help others tweak.