I was printing a very simple cone and it failed, the hotend was in the air still putting out filament. So, I canceled it in Octopi (Octoprint) and instead of going up, it went down crashing into the failed print. Luckily everything seems okay, but I would like to know what happened so it does not happen again. Below is what I had in Octoprint’s gcode scripts.
After print job completes:
G0 Z5 ; unconditionally clear part
;G90 ; go absolute
;G0 X0 Y140 ; move bed forward
G0 Z50 ; raise nozzle for cleaning
After print job is cancelled:
; disable motors
M84
;disable all heaters
{% snippet 'disable_hotends' %}
{% snippet 'disable_bed' %}
;disable fan
M106 S0
G0 Z5 ; unconditionally clear part
;G90 ; go absolute
;G0 X0 Y140 ; move bed forward
G0 Z50 ; raise nozzle for cleaning
Well, I have some more information. I think something happened to either the control board or the power supply or both. I had noticed when it was printing that it was really slow, but did not pay that much attention to it. After the crash, I tried leveling the bed again and the stepper motors for the x and y were really slow. It took a good 30 seconds to go from one leveling point to another. So, I turned the power supply off and back on. Everything is now working again though I have yet to cancel a print and see what happens.
If you did not mess with the OctoPrint scripts, aborting just does that.
It stops sending commands to the printer. The only thing it sends is to turn temperatures off, but AFAIR you can setup a command chain to be used when aborting, but this may dangerous
I would agree with you if I had not added the gcode to raise the Z axis upon cancelling. I had been using the gcode for sometime and it always worked. I truly believe that it had something to do with why I had to toggle the power supply on and off. I suspect the main control board had an issue. It is an 8-bit board and the firmware is from TH3D and is pretty much maxed out.
After toggling the power supply, when I cancelled a print, the Z axis raised almost immediately. Now, if I had stopped the print at the printer, it probably would have just stopped where it was and I would have had to raise it manually.
Why would it be dangerous to have a script that raises the Z axis when the print is stopped in Octoprint?
Just looking in your code: You disabled the motors. This is bad. The printer then looses (on purpose) its coordinates and only a homing movement is allowed in this state. Move that line to the end, or your code to the top and everything should be fine.
Loosing the coords is normal. The printer does not know if the bridge was moved by hand or starts sinking on its own (delta printers). So in case of turning off the motors this prevents a crash as the tool head position may have changed. Endstops are not used/checked while printing, so there is no other way. This probably could be fixed with modern 32bit boards and adjustments in marlin, but without this security feature and the addition of additional endstops at x/y max position this is still not a good idea.
You may also need to force marlin to relative/absolute. mode, depending on your needs. To raise the head, you need relative mode.
Depending on the print state at whom you aborted you need to use a different G1 command to move the tool head.
e.g. If the printer is still in relative mode, you g1 Z10 moves Z 10mm up. BUT if the printer is in absolute mode it moves the print head (up or down) to 10mm height, which causes a crash.
This depends on the slicer and where you aborted the printer. The current state is unknown. So use a G91 before the first G1 command to be always on the save side, when moving z.
In start/stop gcode it does not matter what you use, as long as you know what mode you use. Other scripts e.g. when modifying gcode using a script, you may need to know which mode was used, or you would return to print in the wrong mode and suddenly your printer would be driving in one corner interpreting the small relative values as absolute coordinates.
There is no command to cancel a print. You need a couple of commands to shut down the printer properly, like disengaging the motors and to shut of the heaters.
You can for sure put it to the end.
It just turns of the motors, so you can move them by hand again and the drivers aren´t forcing the static position of the tool head.
Maybe the printer was in absolute position mode when the “G0 z5” was executed. Adding a G91 before that command would make sure the printer is in relative position mode. (I’m too tired to test atm, sorry.)
I had the crazy thought that executing M84 prior to the move commands might confuse the firmware, hence my question to Geit above.