[BUG] M0 injection on end of SD card causing nozzle to linger heated on model

[mikeshub]

Description

This is due to lines 769 - 780 in queue.cpp. This is causing the printer to leave the nozzle hot and sitting on my print before executing the code from "End G-Code" in Cura. Disabling event lights stops this from happening. This is obviously not ideal.

I assume there has been some fairly recent change to how it detects being done with an SD print because I previously did not have this issue.

#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

Steps to Reproduce

Have an LCD, use event lights, and print from an SD card using G code sliced from Cura. I will try with Simplify and Slic3r later.

Expected behavior:

The print should execute the end g code and not sit the still heating nozzle on my print.

Actual behavior:

Ruined models

Additional Information

Commenting out the code wrapped in HAS_RESUME_CONTINUE fixes this issue.

[shitcreek]

Marlin just reads through the gcode, there is no such thing as an 'end gcode' as far as it is concerned. Does your end gcode tell the print head to move out of the way?

[mikeshub]

This is a bug report not a support request. Your understanding of Marlin's functionality is dated. If you look at the code I posted you can see where the g code is inserted. This insertion was not an issue quite recently. I have an idea about what's causing the improper end of SD file detection and will mess with it tonight if I have time.

To clarify it previously completed all the g code in an sd file then the g code was inserted at the proper place after the file was complete. Now the inserted command comes too soon.

Personally I think this feature is useless and should just be removed. If not removed it needs a far better method of detecting end of SD files. Bare minimum it needs a define to disable this behavior.

[mikeshub]

This should help to clarify things I have attached g code and the capture from the serial.

Important part of the log:

1564511164,echo:busy: processing
1564511166,echo:busy: processing
1564511168,echo:busy: processing
1564511170,echo:busy: processing
1564511173,echo:busy: processing
1564511640,CRUMB1
1564511644,Done printing file
1564511644,//action:prompt_end
1564511644,//action:prompt_begin M0/1 Break Called
1564511644,//action:prompt_button Continue
1564511644,//action:prompt_show
1564511646,echo:busy: paused for user
1564511648,echo:busy: paused for user
1564511650,echo:busy: paused for user
1564511652,echo:busy: paused for user
1564511654,echo:busy: paused for user
1564511656,echo:busy: paused for user
1564511658,echo:busy: paused for user
1564511660,echo:busy: paused for user
1564511662,echo:busy: paused for user
1564511664,echo:busy: paused for user
1564511666,echo:busy: paused for user
1564511668,echo:busy: paused for user
1564511670,echo:busy: paused for user
1564511671,CRUMB2
1564511671,CRUMB3
1564511671,CRUMB4
1564511673,echo:busy: processing
1564511675,echo:busy: processing

Important part of the g code:

M118 CRUMB1
;TIME_ELAPSED:467.651819
G1 F2400 E87.37331
M118 CRUMB2
M140 S0
M204 S4000
M118 CRUMB3
M107
M118 CRUMB4
G1 X-130 Y-75 Z75 F1000 ; <-------- this is where the cura end code starts. 
M140 S0; cool down HBP
M104 T0 S0 ; cool down right extruder
M104 T1 S0 ; cool down left extruder
M107 ; stop blower fan
M18 ; disable stepper
M82 ;absolute extrusion mode
M104 S0
;End of Gcode

This means that M0 is getting injected before it even gets to the "end g code" section.

3d printing.zip

[InsanityAutomation]

I like the use of host prompts to diagnose :)

[ManuelMcLure]

It looks like inject_P() is the wrong function to use since it aborts the queue. It looks like the other function that takes a PSTR (enqueue_one_now_P()) has limitations on its use so it might not be possible to just switch to that function.

[7eggert]

I hat "click to continue" anyway, so I did the following:

diff --git a/Marlin/src/gcode/queue.cpp b/Marlin/src/gcode/queue.cpp
index f448efb..706525f 100644
--- a/Marlin/src/gcode/queue.cpp
+++ b/Marlin/src/gcode/queue.cpp
@@ -753,7 +753,7 @@ inline void get_serial_commands() {
             SERIAL_ECHOLNPGM(MSG_FILE_PRINTED);
             #if ENABLED(PRINTER_EVENT_LEDS)
               printerEventLEDs.onPrintCompleted();
-              #if HAS_RESUME_CONTINUE
+/*              #if HAS_RESUME_CONTINUE
                 enqueue_and_echo_commands_P(PSTR("M0 S"
                   #if HAS_LCD_MENU
                     "1800"
@@ -762,7 +762,7 @@ inline void get_serial_commands() {
                   #endif
                 ));
               #endif
-            #endif // PRINTER_EVENT_LEDS
+*/            #endif // PRINTER_EVENT_LEDS
           }
         }
         else if (n == -1)

[boelle]

@mikeshub is the problem 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.

[tol2cj]

Looks like this code works in my case, so far. Heated nozzle stopped on printed part with original marlin code.

            #if ENABLED(PRINTER_EVENT_LEDS)
              printerEventLEDs.onPrintCompleted();
              #if HAS_RESUME_CONTINUE
              enqueue_now_P(PSTR("M0 S"
                //inject_P(PSTR("M0 S"
                  #if HAS_LCD_MENU
                    "1800"
                  #else
                    "60"
                  #endif
                ));

[thinkyhead]

@tol2cj — We have a winner! It's amazing how long an issue can go before someone with moxie comes along with the correct cause and the correct solution.

Indeed, the command injection was out of order, and your solution makes sure that heaters and other things in your ending g-code (which tends to be near the end of the file) gets executed, whereas previously the M0 was getting stuck into the queue ahead of the M104 S0 and other useful items that prevent your printer from melting.

Mea culpa, however! When I did a reform and audit of the G-code injection stuff, I totally missed this one.

[tol2cj]

Hi, I have a doubt about "mine solution", today is not working. Why there is "Q" parameter after the "M0", now?

[tol2cj]

I am so sorry, I have tested that on too short g-code. Preseted solution is not correct. Because I am not as versed in Marlin code I am going to comment out block of HAS_RESUME_CONTINUE condition and place M0 on the end of my gcodes.

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