[BUG] Printer pausing at end of print "Click to resume"

[ArketypeDesign]

Bug Description

Previous post on this issue was closed- and response said that this was fixed but I am still seeing the issue with the latest bugfix-2.0.x downloaded on 2-07-20

The nozzle welds itself to the top of the print because it pauses before completing any ending G-code (to move Z axis away from the print).

SKR1.3 board on custom Core XY

My Configurations

Archive.zip Ending G-code script M104 S0 ; turn off extruder M106 S0 ; turn off cooling fan G1 Z195 F1200 ; lower bed G1 X0 Y0 ; Home X and Y M84 ; disable motors

Steps to Reproduce

1. Print any g-code file- printer pauses at end.

Expected behavior: Execution of ending G-code after successful print

Actual behavior: after successful print, printer enters "pause" mode with "click to resume" on screen. This happens before ending g-code is executed.

Additional Information

Video: https://www.dropbox.com/s/95gzg79v6955cu9/ClicktoResume.mp4?dl=0

Here is the gcode for the Benchy in the video..... 3DBenchy-080Noz-e-03L.gcode.zip

[sjasonsmith]

Somebody else just reported what sounds like the same thing when testing another issue I worked on (linked above).

I could have sworn I have already seen this behavior reported and supposedly fixed in the past week. Was that something you had looked at, @thinkyhead?

[carl1961]

I had same issue with all marlin versions, I am running the latest 2.0 (downloaded yesterday) stops at last couple lines in code ( when LED statis turns Green ,I think )it has to do with the 5050 LED's I have led enabled. work around is doing this: C:\BIGTREETECH\Marlin-2.0.x\Marlin\src\gcode\queue.cpp starts at Line: 536 - 544

@shitcreek commented on Aug 25, 2019 • Since you have #define PCA9533 enabled I think this has more to do with PRINTER_EVENT_LEDS #14774. The current work around is to comment out

#if HAS_RESUME_CONTINUE
  inject_P(PSTR("M0 S"
    #if HAS_LCD_MENU
      "1800"
    #else
      "60"
    #endif
  ));
#endif

in queue.cpp

15054

[PM3Delta]

Since Feb 4th the 2.0.x-bugfix fixed that issue for me. I had presumed that #16753 had taken care of it. I might be mistaken though.

[thinkyhead]

What are we looking for in that log?

[thinkyhead]

Well, there is no indication where the pause occurred. Use M111 S3 to enable echoing of every command that arrives, wait for the pause to occur and take note of the log at that point.

[thinkyhead]

As for the original issue, if you have PRINTER_EVENT_LEDS enabled, this is a feature. The print pauses at the end to let the light stay at the "print completed" color for 30 minutes (or just 1 minute if you have no LCD controller) before going back to the neutral "idle" color.

[thinkyhead]

Can you please describe the strange behavior you are seeing in a concise manner to save time for the weary reader?

[thinkyhead]

I understand that your issue is different. This is why we prefer that people do not piggyback on similar but most likely unrelated issues.

[carl1961]

@thinkyhead The op and me have #define RGB_LED enabled, at the last layer or maybe two layers the marlin firmware will stop ( with hot end on print ) until you press the encoder to resume. it happens when the led turns green on my 3d printer. only workaround was commenting those lines out in queue.cpp . i know that is not the correct fix but it gets us going. If I comment out #define RGB_LED where the led stop working, the issue goes away so it must be in the code for the event led lights that turn different colors for different stages of the print job.

[thinkyhead]

I'm adding an (undocumented) Q parameter to M0/M1 so that the screen won't read "Click to Resume…" but will show the total print time at the end of the print. However, it will still be waiting for a click. That will be merged before too long… A more complete solution will skip using M0/M1 altogether.

[thisiskeithb]

If I comment out #define RGB_LED where the led stop working, the issue goes away

That was the source of the pause I was experiencing. Thanks for finding it!

[carl1961]

@thisiskeithb been studying this gode since thinkhead mentioned M0/M1

is might be more related to onPrintCompleted , thats when the green led come on.

file printer_event_leds.h

 #if ENABLED(SDSUPPORT)

    static inline void onPrintCompleted() {
      leds.set_green();
      #if HAS_LEDS_OFF_FLAG
        leds_off_after_print = true;
      #else
        safe_delay(2000);
        set_done();
      #endif
    }

[ArketypeDesign]

OK... my mistake- I had RGB enabled (I do not have RGB lights on this printer). So this is no longer a problem for me.

Still- for those with lights it looks like the "pause" occurs before all of the ending g-code is excecuted, which I think is still a problem.

[thinkyhead]

Still- for those with lights it looks like the "pause" occurs before all of the ending g-code is excecuted, which I think is still a problem.

It is only used for SD printing, and only after queueing the last command from the card. So… it's mysterious.

[thinkyhead]

There was a bug in the command injection at the end of SD printing, so M0 was being executed ahead of the final commands in the G-code file. This has now been patched. Since this is a safety issue, I recommend you update your copy of Marlin soon, and for extra safety on machines that might not have this update, be sure to put an M400 at the end of all your G-code files and in your slicer custom end g-code.

[thisiskeithb]

We still saw this bug with M400 in our end gcodes, but I rebased my configs on the latest commit, so we should be covered.

Thanks for the patch!

[thinkyhead]

Of course, the M400 also doesn't get reached. 🤦‍♂

[ghost]

@thinkyhead :

I'm adding an (undocumented) Q parameter to M0/M1 so that the screen won't read "Click to Resume…" but will show the total print time at the end of the print. However, it will still be waiting for a click. That will be merged before too long… A more complete solution will skip using M0/M1 altogether.

This breaks the lcd menu on printers with status led enabled, there never is a "click to resume" nor does it listen to any click after that, led stays green, can't confirm/use any action that relies on sending Gcode (homing / etc...) but I can navigate my SD and start a print (not sure if it starts the print as i didn't try), rebooting the printer works, using a bugfix tree from before the coolstep imp/revert doesn't show this bug (this commit in particular : https://github.com/MarlinFirmware/Marlin/commit/0ce83dee9560fc30f27fdddc450d3861725d9a22 ).

[thinkyhead]

nor does it listen to any click after that

I'm messing around with this and should have it sorted soon.

[jwebber23]

I have the same issue running 2.0.3 on a BTT SKR MINI E3 V1.2. If i enable my NEOPIXEl's i get the green lights and Click to Resume a few lines before the end of the print (before any of my end g-code runs). If is disable them it run to the end as expected.

I have created a short G Code run without the Bed and Extruder heating and this gives the same results, NEOPIXEL's on => stops early NEOPIXEL's off => works fine.

How does the code determine the "end of the print" from the SD card?

I have commented out the PRINTER_EVENT_LEDS so i can keep my LED's and not have the current Click to Resume issue.

#if ANY(BLINKM, RGB_LED, RGBW_LED, PCA9632, PCA9533, NEOPIXEL_LED) //#define PRINTER_EVENT_LEDS #endif

[ghost]

I'm messing around with this and should have it sorted soon.

My bad, EU time here, saw that as I started reflashing / running a debug gcode.. oh well, glad you found something, I'll still add some debug logs to my opened issue.

@jwebber23 : Use the bugfix branch, It was supposed to be fixed 5-6 days ago.

Also, I never had the bug this issue refers to, RGB led and PRINTER_EVENT_LEDS always worked since 1.x for my setup, so... what kind of slicer do y'all use ?

[jwebber23]

I'm messing around with this and should have it sorted soon.

My bad, EU time here, saw that as I started reflashing / running a debug gcode.. oh well, glad you found something, I'll still add some debug logs to my opened issue.

@jwebber23 : Use the bugfix branch, It was supposed to be fixed 5-6 days ago.

Also, I never had the bug this issue refers to, RGB led and PRINTER_EVENT_LEDS always worked since 1.x for my setup, so... what kind of slicer do y'all use ?

I am currently using Prusa Slicer but will transfer to Simplify 3D and see if there is any change. I will try a build tomorrow with the Bug Fix. I don't have enough pins for RGB so will have to stick with Neopixels.

[ghost]

I use Cura here and the gcode from SD works and triggers the correct screen.
Neopixel or RGB should behave the same, also worth checking if you didn't scuff :

define EVENT_GCODE_SD_STOP "G28XY" // G-code to run on Stop Print (e.g., "G28XY" or "G27")

If you changed this line, make sure you use "\n" to separate each gcodes (like "G28XY\n M150 R0 U0 B0") If you're using leds anyway, I guess the current bugfix might not help (as the "click to resume" post-print screen is gone for us, led users). Wait for https://github.com/MarlinFirmware/Marlin/issues/16878 to be solved 📦

[jwebber23]

I have now tried 2.0.4 (downloaded today) and latest Bugfix (downloaded today) and both now stop near the end and i no longer get the click to continue. I have tried with Simply 3D and self generated test G-Code all with the same result.

Not sure if a fix has been put in any of the versions of code but it appears worse as without the click to continue you need to turn off the printer to do anything.....

[ghost]

@jwebber23 : https://github.com/MarlinFirmware/Marlin/issues/16908 Didn't try myself, but apparently ellensp found the problem and posted a fix, too bad it missed the release mark.

[thinkyhead]

I agree that onPrintCompleted CardReader::printingHasFinished has an issue. An SD print is considered completed as soon as the last command is read from the SD card and (presumably) stored in the g-code queue. The queue is typically about 4 items long. Some configs make it 10. And recently I've seen issues connected to a queue that was 64 commands long (though usually not anywhere close to full).

The onPrintCompleted CardReader::printingHasFinished method is called before the items in the queue are processed.

The injection of M0 should be okay in itself, because this goes to the end of the queue at the point where the last command from SD has been added. You can enable echo logging with M111 S3 and connect a host during a test print to see the exact order that commands are getting processed. I'll take a look at this over the weekend, as it may require some extra logic to make sure the print is only flagged as done when the last command has actually been processed.

[ghost]

Don't sweat it, according to this : https://github.com/MarlinFirmware/Marlin/pull/16921/files
It looks like you inverted some operators when tidying up the loop, that might explain why it didn't show the "click to resume" (or shows it for a split second before moving on) and didn't register any clicks either.

[jwebber23]

That would explain it once the last line is read from the SD card rather than executed. Was the bugfix fix added to 2.0.4 as well as that had the same result with the missing or brief Click to resume.?

[thinkyhead]

It looks like you inverted some operators…

Yeah, that typo is one of many I let fall in this week due to lack of sleep while pushing Auto Build through. I'm taking it much slower this week.

So, please give the latest code a test. There may still be an issue with CardReader::printingHasFinished that could manifest under some circumstances. Specifically, what will happen is as soon as the end of the file is reached, CardReader::printingHasFinished calls planner.synchronize so if there's a move on the last line of the g-code file there would be a pause in the motion before it executed. That's not too serious, but printingHasFinished does a bit more besides…

• Calls finish_and_disable which disables all steppers (if SD_FINISHED_RELEASECOMMAND)
• Enqueues M31 or M117 (waiting for queue space to open up)
• May re-select the file in the UI.

All these tasks are fine if done at the right time, but these closing steps could come in ahead of the last line in the G-code file. And if the next-to-last move is very long, other oddities can arise. The out-of-order or delayed execution of the last line in the g-code file is what you should look for with M111 S3 and I will be confirming this on my setup as well.

[ghost]

@jwebber23 : the fix is in bugfix and 2.0.4.2 (today's maintenance release).

due to lack of sleep

Don't force-push yourself too much ;)

[jwebber23]

Hi,

I just tried 2.0.4.3 and it still is stopping before the end of the SD card and not displaying the Click to resume. Once you click it doesn't continue and you cant release the media either. I have uploaded the platformio and my 2 config files in case there is something wrong with them which is causing my issue. I will give bugfix a go tonight. Config.zip

edit..... I have just tried the latest bugfix and got the same results. Stops early and then stops you moving axis on the printer, releasing the media etc.

Just to confirm i have an Ender 3 Pro with a Bigtreetech SKR Mini E3 board. I am using Visual Studio Code to compile the code.

[ghost]

I didn't run any print since this weekend, but as far as I know, the issue you posted here was fixed.
Related to sdprint and since then, this happened : https://github.com/MarlinFirmware/Marlin/issues/16936 .
Can you do a tiny print and send "M111 S3" to see what happens at the end of it ?

[jwebber23]

M111.zip I have run it with the latest bug fix.

Attached is the text from Pronterface and the g code i ran. It stops at line 122, a long way short of the end of the code. This code runs fine in 2.0.4 when i comment out the PRINTER_EVENT_LEDS or earlier version when i don't enable the Neopixels

#if ANY(BLINKM, RGB_LED, RGBW_LED, PCA9632, PCA9533, NEOPIXEL_LED) //#define PRINTER_EVENT_LEDS #endif

[thinkyhead]

How big is your BUFSIZE?

[ghost]

from the config.zip posted a few post higher, he has BLOCK_BUFFER_SIZE 32

[jwebber23]

I'm not sure. I have attached the configuration files a few posts back. It would be the default bigtreetech size for SKR mini E3. I am not in front of the machine until tomorrow.

[thinkyhead]

The current bug appears to be caused by mis-use (or, over-use) of the queue.inject_now_P method from places in the Marlin program flow where it can lead to a freeze. Please give #16967 a test.

[thinkyhead]

I've merged the patch with additional assurances to prevent a blocked queue, and yesterday patched a click-handling 🤦‍♂ bug in M0/M1.

[jwebber23]

Which version is the fix in? Thanks

[thinkyhead]

All such changes go into bugfix-2.0.x of course.

[jwebber23]

M111 S3.txt Hi,

It now gets through the file before the Click to Resume which is great. The Green LED's come on a good few lines before it is finished running the g code. Attached is the M111 S3 for this job.

[thinkyhead]

The Green LED's come on a good few lines before it is finished running the g code.

That's because they aren't turned on by adding to the queue, but immediately upon reaching the end of the file. We don't have a G-code for "call the LED onPrintCompleted method" but it's possible to add one and force the event into the queue.

[jwebber23]

Thanks for that. Will this fix make it into 2.0.4?

[thinkyhead]

Yes, the fix has already been merged into bugfix-2.0.x.

[jwebber23]

Sorry, I meant the non bugfix version 2.0.4?

[carl1961]

I verify , the fix merged into bugfix-2.0.x fixes the issue. Thanks @thinkyhead and all who helped!

[thinkyhead]

@jwebber23 — Now that 2.0.4.4 is out, yerp!

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