Printing again after a cancel skips important gcode

Get Help
1

What is the problem?
After I cancel a print, when I try to reprint the file by clicking the print icon again, an important part of my gcode is skipped -> the line that I print outside my print area to ensure filament is flowing smoothly. I know the gcode is there. It worked the first time before I canceled, and I can see it when I click the edit button.

However, if I try to print the same file again, it skips that part and usually the print fails again because the filament is not flowing smoothly - a very frustrating cycle -> failed print leads to failed print leads to failed print!

Maybe this is the expected behavior (to experienced users), but to a newbie, I don't understand why a "cancel" wouldn't cause the next print to start from the very beginning. Is octoprint looking for a specific gcode to start from? Could it be my after cancel gcode (below:)?

G91; Set to Relative position
G1 E-1 F300; retract the filament a bit before lifting the nozzle
G0 Z250; move z axis 
G28 X Y; home X axis

M106 S0 ; Turn off fan
M18; Disable all stepper motors
M84; Stop idle hold
M85 S300; if incative for 5 min, shutdown

What did you already try to solve it?
I'm relatively new to Octoprint. I tried searching the forums and came across the "Log position on cancel" option. I unchecked that but no change in behavior.

Logs

2020-01-24 19:49:46,365 - octoprint.util.comm - INFO - Changing monitoring state from "Starting" to "Printing"
2020-01-24 19:49:48,507 - octoprint.util.comm - INFO - Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
2020-01-24 19:50:31,462 - octoprint.util.comm - INFO - Telling the printer to set the busy interval to our "communicationBusy" timeout - 1s = 2s
2020-01-24 19:53:44,625 - octoprint.plugins.excluderegion - INFO - Printing stopped: event=PrintCancelling
2020-01-24 19:53:44,625 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Cancelling"
2020-01-24 19:53:44,632 - octoprint.util.comm - INFO - Force-sending M108 to the printer
2020-01-24 19:53:44,644 - octoprint.printer.standard.job - INFO - Print job cancelled - origin: local, path: mirror_holder.gcode, owner: piOctoPrint, user: piOctoPrint
2020-01-24 19:53:44,647 - octoprint.plugins.excluderegion - INFO - Printing stopped: event=PrintCancelled
2020-01-24 19:53:44,747 - octoprint.plugins.excluderegion - INFO - Printing stopped: event=PrintFailed
2020-01-24 19:54:41,998 - octoprint.util.comm - INFO - Changing monitoring state from "Cancelling" to "Operational"
2020-01-24 19:55:01,863 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Starting"
2020-01-24 19:55:01,873 - octoprint.printer.standard.job - INFO - Print job started - origin: local, path: mirror_holder.gcode, owner: piOctoPrint, user: piOctoPrint
2020-01-24 19:55:01,882 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2020-01-24 19:55:01,897 - octoprint.events - INFO - Executing a system command
2020-01-24 19:55:01,905 - octoprint.util.comm - INFO - Changing monitoring state from "Starting" to "Printing"
2020-01-24 19:55:01,907 - octoprint.plugins.excluderegion - INFO - Printing started
2020-01-24 19:57:06,007 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Cancelling"
2020-01-24 19:57:06,015 - octoprint.util.comm - INFO - Force-sending M108 to the printer

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
Octoprint 1.3.12, Marlin 1.1.x bugfix branch, Ender 5

2

Hi @KB-learning!

Have you setup the Custom Bounding Box in the Printer profile?

3

Not familiar with that option, but it looks like it's unchecked.

4

You may set it up with a certain area for that prime line depending where it printed.
If it is e.g. at Y-2 then you may set a value for Y of -5 or so in the Custom Bounding Box.

5

I'm not sure this is relevant to the "1st print" vs "1st print -> cancel -> reprint behavior". What does a bounding box have to do with that if the line works for some prints, but on canceled prints, the same gcode is "skipped".

But like I said, I'm new to octoprint, so maybe it is relevant, but it's not intuitive that it would be related. Anyway here the prime line gcode (just 2 simple lines (back and forth):

G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position
G1 X10.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line
M73 Q0 S49
M73 P0 R51
G1 X10.4 Y200.0 Z0.28 F5000.0 ;Move to side a little
G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line
G1 Z2.0 F3000 ;Move Z Axis up
G1 F2400 E-7
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0`Preformatted text`
6

I assumed that line had a negative value in X or Y direction

As I see, that line is printed at Z0.28 and I assume that first layer is at Z0.20.

You may have a look here: https://github.com/foosel/OctoPrint/issues/3339

7

I guess "outside my print area" is a bit ambiguous. Still not sure why it would be relevant to a cancel being called when it works the first time. Still, the coordinates are not negative, and the entire first layer is 0.28, not just that line.

Also looked at the github issue, no one mentions anything about "canceling" a print, and I really believe that's the crux of the issue here.

I can reliably reproduce this behavior on any of my prints sent to octoprint, by cancelling during the print, and then restarting it by clicking the printer icon in the UI regardless of whether or not the print would have successfully completed.

8

Try adding an explicit G90 to your start gcode or to the end of your cancel gcode to put the printer back in absolute positioning mode. What could be happening is that the printer remains in relative positioning mode and any commands in your start gcode are being interpreted as such.
I had a similar issue that was caused by that. My start gcode moves the nozzle to a position off the bed but when I had canceled a print it would go to an apparently random position instead.

2 Likes
9

Have you already tried with unchecking Sort Layers yet as mentioned in the link?

10

@Ewald_Ikemann Why (AFAIK) would a setting of the purely visual renderer have an affect on the printer's actual gcode processing? "Sort layers" was unchecked, but even if it was checked, I'm really not understanding why you think this would impact the printer skipping gcode while actually printing.

11

As best as I can tell, it's not a relative vs absolute issue. When it tries to print again, it starts with the model, not the straight line that I prime with off to the side. If it was a relative positioning issue, it would still start with the straight line - just offset. Watching the gcode in the terminal output as it prints, confirms this as well as just watching the print ... it's clearly not trying to print a straight line.

12

I'm really sorry that I tried to help you...

In such a complex thing lie OctoPrint many things can happen.
To find a solution is to exclude those things that don't cause the fault. Even if they seem not responsible.
Also see this: GCODE viewer inserting do-nothing layer, and print fails at that layer

13

For anyone else having the same issue - I can confirm that after looking at my GCODE the start GCODE didn't have G90 set at the start. It was only present BEFORE the print itself, nor the cancel GCODE had G90 set, only the 'complete' GCODE performed a reset of everything. So when the print starts after a cancellation, it was indeed set to relative positioning making the purge line GOCDE basically invalid. Setting the G90 at the end of the 'cancel' GOCDE solved the issue.