[BUG] Click to resume... on the end of sd card printing

[etet100]

Description

It may be similar to old issue https://github.com/MarlinFirmware/Marlin/issues/6503

My board is Mightyboard (Flashforge Creator Pro) with most recent version Marlin bugfix-2.0.x. After last line of SD card gcode my printer stops with "Click to resume..." message. Not of all command are executed. Everything is perfectly fine if i print via usb.

Steps to Reproduce

1. Run any gcode from SD Card (a few lines or thousands of lines, doesn't matter)
2. Wait until printer finishes
3. Check LCD (heaters are not turned off, the nozzle is burning printed object, printer is waiting for my action)

Expected behavior:

Finish printing, execute every command from file, disable heaters, move away from printed object.

Actual behavior:

After reading last line of gcode printer is waiting for my action. A few lines from file are not executed until i click Resume. My item is ruined.

Additional Information

None

MarlinMightyboard.zip

[shitcreek]

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

[thinkyhead]

We'll have this sorted soon. The location of the end of print event makes it tricky to coordinate the status LED color code with the parking behavior. This might be a good candidate for an internal-only G-code.

[axl12ap]

Same problem with github version of August 28, my configuration files are attacched to the reply.

Need to press encoder button to proceed to executing commands of end script. Please think about a workaround RailBOT_2_4-(19-08-28).zip

[Roxy-3D]

Please think about a workaround

I suspect you could artificially lengthen the GCode file with benign commands to ensure the important stuff at the end of the file (end code generated by the Slicer) is still executed.

If you added 150 lines of M114 to the file, my guess is everything important will get executed prior to the pause.

Sort of along the lines Thinky is suggesting... We could have the end of file condition queue up some internal MCode that triggers action that should be taken at the end of a print. That would eliminate the real time code that is trying to detect a pause and/or park behaviour.

[axl12ap]

This's my end script for Cura 4.1:

; --- END Cura gcode --- G92 E0 ; Retract to prevent blob and home G1 E-3 F3600 G28 X0 Y0

M104 S0 ; Power off temperatures M140 S0 G90 G1 Z200 F1000 ; Move plate down to 200mm M84

M109 R50 ; Wait and power off printer M81 ; --- END Cura gcode (End) ---

As you can see @thinkyhead and @Roxy-3D the script was executed from Marlin firmware until it reach the line "M109 R50", then it stops and displays "Click to resume...".

I need that firmware cool the extruder down to 50°C and then power off the printer automatically, at this time it's not possible.

Any advice?

[shitcreek]

@axl12ap see my comment above for the current workaround.

[thinkyhead]

The cooldown at the end isn't possible currently, because as soon as the end of the G-code file is reached (SD printing), the job is over and heaters are immediately disabled.

[thinkyhead]

I have a potential solution for the wait-for-temperature issue. In the Temperature::wait_for_hotend method, change the call to idle() to manage_inactivity() instead.

[axl12ap]

The cooldown at the end isn't possible currently, because as soon as the end of the G-code file is reached (SD printing), the job is over and heaters are immediately disabled.

The cooldown is essential for the correct procedure before power off the printer, and M80/M81 is a feature inside Marlin from a long time. Finally I need to automate the power off procedure, that Marlin offers also from long time...

I found the code lines you proposed in the latest reply but I don't understand the workaround ( change from idle() to manage_inactivity() )... can you explain better how does it works this ?? and how affect on M81 ??

Thanks

[thinkyhead]

…can you explain better…?

Marlin will run M81 while it's waiting inside Temperature::wait_for_hotend because idle keeps processing the G-code queue. Changing this to manage_inactivity causes M81 to wait until Marlin exits Temperature::wait_for_hotend and returns to the main loop.

[axl12ap]

…can you explain better…?

Marlin will run M81 while it's waiting inside Temperature::wait_for_hotend because idle keeps processing the G-code queue. Changing this to manage_inactivity causes M81 to wait until Marlin exits Temperature::wait_for_hotend and returns to the main loop.

Thanks, I'll try this evening when come back home from office... but I'm not sure you understand the main problem :D because marlin now stops and wait you push the "rotating encoder" while displays "Click to resume..." ...it seems to stop the gcode execution before M81 and M109

[AnHardt]

Some additional remarks

G92 E0 ; Retract to prevent blob and home
G1 E-3 F3600
G28 X0 Y0 ; Both of the '0' are useless. If homing to MAX you'll end at max,max.
; Better use G90 followed by G0 X0 Y0 to go to 0,0.
M104 S0 ; Power off temperatures 
; In this combination M104 and M140 are redundant
M140 S0 ; Either use R0, if you want to wait, or this is useless.
G90
G1 Z200 F1000 ; Move plate down to 200mm  
; Maybe a M400 here to not switch motors off before move finished
M84

M109 R50 ; Wait and power off printer M81 ; --- END Cura gcode (End) ---

Pay attention to

define SD_FINISHED_STEPPERRELEASE true // Disable steppers when SD Print is finished

define SD_FINISHED_RELEASECOMMAND "M84 X Y Z E" // You might want to keep the z enabled so your bed stays in place.

when printing from SD. This script could also be extended.

[thinkyhead]

I'm not sure you understand the main problem

I specifically said I was addressing only the one issue (that M109 is/was non-blocking). Eliminating this issue is an important first step to prevent M81 being executed immediately, which kills M109. Once I have feedback on that change and we see what the new behavior is, then with that out of the way the main issue will be open for investigation.

[thinkyhead]

I have already committed the M109 patch to bugfix. 451a942e951d7802342f94d97c4013319c240296

[axl12ap]

Some additional remarks

G92 E0 ; Retract to prevent blob and home
G1 E-3 F3600
G28 X0 Y0 ; Both of the '0' are useless. If homing to MAX you'll end at max,max.
; Better use G90 followed by G0 X0 Y0 to go to 0,0.
M104 S0 ; Power off temperatures 
; In this combination M104 and M140 are redundant
M140 S0 ; Either use R0, if you want to wait, or this is useless.
G90
G1 Z200 F1000 ; Move plate down to 200mm  
; Maybe a M400 here to not switch motors off before move finished
M84

M109 R50 ; Wait and power off printer
M81
; --- END Cura gcode (End) ---

Pay attention to

  #define SD_FINISHED_STEPPERRELEASE true          // Disable steppers when SD Print is finished
  #define SD_FINISHED_RELEASECOMMAND "M84 X Y Z E" // You might want to keep the z enabled so your bed stays in place.

when printing from SD. This script could also be extended.

Forget to disable the two defines about SD_FINISHED :+1: but I prefer to add my customized end script based on the print situation (short time, long time, away from printer, and so on) ...anyway thanks for the tips

[AnHardt]

An other tip. When waiting for more than one heaters, don't do it in a sequence but in parallel, to speed things up. Instead of

M109 R0
M190 R0 ;bed will begin to cool down when E is could.

use

M104 S0 ; Set target for the faster heater to start cooling
M190 R0 ; Wait for the slower heater
M109 R0 ; Wait for the faster heater should now return immediately

[thinkyhead]

A note: After checking closely, turns out the M109 command is actually blocking, so never mind that patch and disregard my earlier comments.

[axl12ap]

A note: After checking closely, turns out the M109 command is actually blocking, so never mind that patch and disregard my earlier comments.

Sorry for the delay but I was out of my home for work. In the next days I'll try the new firmware version... and I'll check the workaround...

[boelle]

@etet100 still having problems?

[axl12ap]

@thinkyhead hi friend... sorry for my late!!

Coming back from work after 1 month out of my city, I tried better yesterday night the script code for cooling hotend and then power off... it works corretcly without any changes in the code (leaving idle() in the temperature::wait_for_hotend)

I don't know why in the past it doesn't work (may be the incorrect script), but if I put: M109 R50 M81

It work correctly!! Thank you my friend This thread can be now close.

[etet100]

NOT FIXED! Please reopen this issue. I have just reverted previously commented

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

and it's waiting with "Click to resume" and heaters on.

[boelle]

@etet100 since 2.0 was just released a few days ago has this changed this issue at all?

[MrJabu]

@etet100 since 2.0 was just released a few days ago has this changed this issue at all?

i'm running into this issue now with 2.0. in Bugfix it worked fine

M104 S0 ;extruder heater off M140 S0 ;heated bed heater off (if you have it) M107 ;fan off G91 ;relative positioning G1 E-1 F300 ;retract the filament a bit before lifting the nozzle to release some of the pressure G1 Z+0.5 E-5 X-20 Y-20 F9000 ;move Z up a bit and retract filament even more G1 Z5; G1 X180 Y180; Z5; Move Z Axis down by 10mm M84 ;steppers off G90 ;absolute positioning

[boelle]

@MrJabu is the issue precise the same as that @etet100 has?

[MrJabu]

@MrJabu is the issue precise the same as that @etet100 has?

at the end of the print is seems to not run the G1 commands and it displays "Click to Resume". Once you click then it finishes running the end script.

[AnHardt]

M400?

[carl1961]

I have same Issue printing from SDCard with RGB Led lights enabled

define RGB_LED

//#define RGBW_LED

if EITHER(RGB_LED, RGBW_LED)

define RGB_LED_R_PIN PF9

define RGB_LED_G_PIN PF8

define RGB_LED_B_PIN PF7

//#define RGB_LED_W_PIN -1

endif

something in PRINTER_EVENT_LEDS at the point it is to turn Green during last couple lines of gcode is when it does the "Click to resume" Hotend still on print.

current Marlin-2.0.x "2019-12-01"

Last line of any thing printed would pause ( melting part) Doing what @shitcreek posted above stopped it. now printing completes fine. and Green LED comes on at last line of Gcode printing.

comment out in file queue.cpp
C:\BIGTREETECH\Marlin-2.0.x\Marlin\src\gcode\queue.cpp

around line 537

else { SERIAL_ECHOLNPGM(MSG_FILE_PRINTED);

if ENABLED(PRINTER_EVENT_LEDS)

          printerEventLEDs.onPrintCompleted();

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

endif // PRINTER_EVENT_LEDS

      }
    }
    else if (n == -1)
      SERIAL_ERROR_MSG(MSG_SD_ERR_READ);

[boelle]

@etet100 is the issue still the same with all the updates in the last 16+ days?

[boelle]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

[MangaValk]

Same issue on skr pro. And I noticed if I enlarge the buffer, the issue starts a few lines before the last gcode lines

[boelle]

@etet100 still no good news with the latest bugfix 2.0.x?

[etet100]

@boelle sorry for the late reply, i was working recently with klipper firmware

still exactly the same issue

the most recent marlin bugfix-v2.0.x

[boelle]

how often do you update? bugfix is updated almost daily

[etet100]

Once a month.

[boelle]

try twice a month or once a week, a lot is going on, could be that your issue is fixed

[boelle]

a lot of updates and fixing has happend in the last week, is the problem still there?

[thisiskeithb]

We're seeing the same "Click to Resume..." behavior with BigTreeTech's BTT002 board (for the Prusa MK3/S) when printing from SD.

The nozzle stops on the part before the final extrusion (while keeping heaters active) and throws up the "Resume..." screen. Once you click resume, there's a final extrusion & then the print completes. On a whim, we added M400 to our slicer's end script with no success.

Printing the same exact gcode using OctoPrint/serial does not cause this behavior and the print completes just like it should.

Here's a link to latest config, but I rebase it on top of bugfix-2.0.x several times a week, so we're always testing the latest code.

Credit: Chris Warkocki/@codiac2600

[thinkyhead]

Sounds like it's getting an M0 or M1. It's odd, because those G-codes will put extra characters in the message string if they aren't nul-terminated.

[thisiskeithb]

I’ll update to the latest commit and then run some proper SD/OctoPrint tests (with logging this time 🙃) and see if anything stands out.

[ArketypeDesign]

I am seeing this issue as well ever since the 2.0 release- At least up until last weeks build. This happens with G-code that printed fine before the official 2.0 release.

Custom Core X-Y with SKR 1.3 board. Glad I found this listed in the forum... At first I thought it was just me ; ) My ending g-code: 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

So it looks like it powers down properly, but pauses just before the G1 command to lower the bed.

[thinkyhead]

This has been patched in the bugfix branch.

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