[bug] PRINTER_EVENT_LEDS not displaying final state

[reven]

Description

Once a print finishes, the LEDs flicker green and then turn off. The message "Click to resume" is displayed.
Details: Anet v1.0 board definition, #define NEOPIXEL_LED and PRINTER_EVENT_LEDS defined. LEDs working as expected for temp ramp up and printing. This is on an Anet A6 printer with the ANET_FULL_GRAPHICS_LCD defined.

Steps to Reproduce

1. Print a file from SD
2. Wait for print to finish

Expected behavior: (As described in config file comment): LEDs should turn green and wait for a button click before turning off.

Actual behavior: LEDs flash green instantly and then turn off.

Additional Information

• ZIP with config files attached: config files.zip.
• This has been observed in 1.1.8bugfix and 2.0bugfix.

[thinkyhead]

Some preliminary questions before we alter this…

• How long should it wait before it gives up and starts accepting G-code again?
• How long should it wait when there's no LCD controller? (Currently 1s, unless EMERGENCY_PARSER is enabled.)
• Should it require M108 to indicate "continue" when there's no LCD controller but EMERGENCY_PARSER is enabled?
• Should it simply leave the LED set to green until it is set by something else?

[reven]

Good questions. IMHO, I think a safe default would be to leave the LEDs on for a longer period of time, say for example 30min, or until anything else happens before that. That would cover almost all of the scenarios you've mentioned.

Also, I don't understand what the pause is for? To continue processing other files? That would require user action anyway, so why not just end processing? There shouldn't be any more gcode left to process. I'm probably missing something here.

[thinkyhead]

The current implementation just adds an "M0" to the queue, so the wait-for-user is done at the print queue level, blocking further commands until either an LCD click or an M108 is given. The G-code queue is actually blocked by any code that sits in a loop calling idle() and Marlin only resumes accepting commands from the host once execution returns to loop().

The PR linked above simply adds a flag that M0/M1 looks for. If the flag is set it turns off the LEDs after the user responds. I've also set the timeout to 60 seconds. This is just in case someone has no LCD controller and also has no idea that EMERGENCY_PARSER provides the M108 alternative. I suppose if an LCD controller is definitely attached, then it could set the timeout to 5 min… 30 min…

[thinkyhead]

Ok, I've updated this to wait up to 30 minutes when there's an LCD controller before turning off LEDs (to save power), one minute when there's only M108, and 2 seconds if there's no possible user interaction. It would be possible to have it wait until any G-code command arrives for the case where there's no LCD (and/or no M108), but since that would add a check to the core parser I'm not implementing that for now.

[reven]

Thank you @thinkyhead! Works like a charm. Thanks for tackling this so quickly.

Just one minor detail, after pressing a button, the LCD still says "Click to resume..." instead of changing to the "Ready" message. If you want I'll open a separate issue for that, just let me know.

[thinkyhead]

The behavior of on-screen messages is undefined for M0/M1. Currently it has the following logic:

• If the command includes a message (and no delay) then show the message.
• If there's a timeout, don't clear the message when the timeout expires or the user responds.

I will post a change so that (for now) it will always return to the "ready" or "resuming" message. In the near future I want to modify the LCD code so that it has a "fallback" message that it returns to when done with something like M0 or other procedures. For example, the fallback message during an SD print would be the long filename, while during non-SD printing it would be "Printing…", or whatever the host has set.

[reven]

Thanks again!

[github-actions]

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.