Marlin: [BUG] Steppers drop steps if they're moving at the same time as neopixel LEDs are updated.

[SysGh-st]

Bug Description

Just modified my Vertex Nano 3D printer with Neopixel strips. Downloaded the latest 2.0.x and updated the firmware for it. Enabled Neopixel support in configuration.h with the correct settings for the strips in question. Also enabled NEOPIXEL_IS_SEQUENTIAL That works as intended.

However. I noticed that when I start a print and the Z-axis moves at the same time as the hotend heats up and the neopixels updates sequentially (as intended) each LED is updated with a new colour, the Z-axis stepper drop one or more steps (It even makes a short audible "click" or a very brief "stop" )
The end results are that the Z-axis drops enough steps to be noticeable out of alignment when it reaches its target position.

The other steppers (X, Y and E) also drops steps if neopixels are updated during a movement.

My Configurations

See linked zip file. Contains actual Configuration.h and Configuration_adv.h
http://ghostnet.sytes.net/Other/VM8600/Configurations.zip

Steps to Reproduce

1. Start a new print. Nozzle (hotend) heats up at the same time as it moves into position.
2. During movement, neopixels change colour as the hotend heats up.
3. Each time a neopixel LED is updated (changes colour), the Z-axis drops one or more steps.

Expected behaviour: [What you expect to happen]
That updating neopixels shouldn't affect the steppers, causing them to drop steps.

Actual behaviour: [What actually happens]
Updating neopixel LEDs while one or more axis moves causes the steppers to drop steps, getting out of alignment.

Additional information.

LED strips have a separate independent power source.
Doesn't matter of LEDs simply change from one colour to another colour, or turned on or off. Even "updating" a LED to the same colour it already has resulted in the same issue: stepper drops steps.
I suspect the routine for updating the neopixels causes the stepper routine to break momentarily.

[GMagician]

AFAIK neopixels are a "beast". They needs a special sequence of bits with strict timing. The code I saw sometime ago disable interrupts to get exact timing. This will stop stepper code from being executed
I don't know if there may be a solution for this

[ellensp]

"NEOPIXEL_PIXELS 30" also BOARD_K8600, isn't that an 8 bit board? It has very few spare cpu cycles.

basically > ~3 NEOPIXEL is basically incompatible with any 8 bit controllers.

[SysGh-st]

ATMEGA2560 is capable of running quite a bunch of neopixels otherwise. I made a 64 pixel (8x8) neopixel "display with it once. Capable of 10-15 fps streaming data from sdcard once upon a time. A measly 30 pixels should be a a breeze for the atmega2560.
(EDIT: Confused another larger display project using a different but similar controller with more RAM. Updated to refect reality.)

Anyhow. My current workaround for the time being is to make sure any pixel updates happen when there's no stepper movements. I changed the printer start routine so it activates heating after moving into priming position, and not during.

I understand the requirement for the exact timing, thus the need to "stop" stepper movement for a brief fraction of a second. The solution would be to let the stepper routine to pause for that brief moment instead of simply dropping steps. Maybe a check to see if the target is an 8 bit controller, and implement the micropause during pixel update.

[GMagician]

ATMEGA2560 is capable of running quite a bunch of neopixels otherwise

that may be true but Marlin has more thing to do than turning on some leds. PWM, LCD, stepper clocking, serial communication or SD reading, and as I told you before neopixels needs a very precise timed sequence of bits to proberly enlight leds. Since this sequence is done sequentially, for all the time you have not to interrupt it otherwise weird thing will happens.
As said for the whole communication time no one can interrupt it...even the stepper code...that's why you see lost step (or weird sounds)

[Powerprobot]

I have an idea... Marlin send an uncritical command to the I2C bus to an ArduinoNano and the Nano control the Neopixel. Neopixels have low order range for me (Today i have no Neopixel.... i didn't need them), but i prefer the print quality.

[SysGh-st]

I have an idea... Marlin send an uncritical command to the I2C bus to an ArduinoNano and the Nano control the Neopixel. Neopixels have low order range for me (Today i have no Neopixel.... i didn't need them), but i prefer the print quality.

I'll try to implement that solution on my end. See where I get. I have a bunch of tiny arduino boards scrapping around all over the place.

[boelle]

@SysGh-st is the issue still there?

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.