When using the manual controls, I accidentally clicked the Move Z "down button" instead of the X/Y button. The nozzle was just barely above the print bed and the nozzle crashed & rammed into the PEI plate. I had to power off to stop it then hope nothing was damaged.
Is there a way to prevent OctoPrint from moving the nozzle too far down? Maybe prevent ANY Z-Axis move below 0? My Taz 6 has a Z height "pushbutton" but I'm willing to adjust that above 0 (& the offsets) if needed.
Any ideas, suggestions, help would be greatly appreciated.
To clarify, I suppose we need to define the scope of this suggestion:
-
At any time, the nozzle should never move below z=0.
-
Under manual movements in the Control tab, the nozzle should never move below z=0.
If it's the first, then this would be a good safety measure but it seems like it would need to be inline for all streaming gcode to the printer. The code would need to know what to do if a move wanted to go too low. Although it's a good idea, the work would need to be well-tested.
If it's the second, then this is probably a good idea and without any caveats.
I myself have drilled a hot nozzle into my plastic bed at least once already (although this occurred while resuming from a print job). In my case, the manufacturer's stock pause/resume scripts didn't factor in the possibility that motor movements could be either absolute/relative.
To further describe the problem: imagine pausing a print job, the first OctoPrint gcode script then moves the assembly but doesn't first go into relative movement mode. You then press the resume button and the second script returns to absolute mode and then moves the assembly back. When the original gcode resumes, the motor audit is now totally off and the hotend attempts to move but crashes into your bed.
It's such a pain in the butt that there's no way to query the axis mode from the printer! It would save SO MUCH PAIN for everyone who develops software like Octoprint. It's one of the reasons that my plugin requires (by default, this can be can overridden) a G90/G91 + M82/M83 before starting a timelapse. Without actually seeing this gcode I can't be sure my program won't ram the nozzle into something or move the XY carriage out of bounds.
Unless the firmware adapts by allowing gcode to query all axis modes and can always report the actual current X/Y/Z positions (and a lot more actually) without a home (or with a safe 'home to maximum and return'), I don't see any clean solution to the issue. If the protections that Octolapse uses (require G90/G91 as well as a homed axis) were added to Octoprint there would be TONS of complaints, similar to the 'Octolapse won't start' issues I see every day. In fact, I'm considering setting default axis modes for the current printer profiles to reduce the number of support requests I see, though this could also lead to an occasional nozzle to crash into the part/bed, the extruder to jam, or to the XY axis running into endstops.
TLDR: There is no way to win here with current printer firmware. You can prevent the crash but that will cause other less severe issues, but they will occur WAY WAY more often.
Baby steps, then...
What if there were a simple plugin which remembers what mode the motors are in (relative/absolute)? It would save M82/M83 state as well as G90/G91. You could query the plugin for this information.
M114 should report back the current position.
Turning my printer on, I run an M114:
Send: M114
Recv: X:0.00 Y:0.00 Z:-15.00 E:0.00 Count X: 0 Y:0 Z:-12000
I then home both X/Y and Z on the Control tab and repeat the M114 to see:
Send: M114
Recv: X:0.00 Y:127.00 Z:145.00 E:0.00 Count X: 0 Y:10160 Z:116000
This now is more trustworthy because it's been homed. None of the OctoPrint gcode scripts have had a chance to run but I include homing commands in my Before print job starts script.
Pressing the button to jog the Z by 10mm, I see the following sandwich of gcode sent to the printer. Note that octoprint itself is making an assumption that I need to go back into absolute mode when this jog is finished.
Send: G91 # set relative mode
Send: G1 Z-10 F200
Send: G90 # set absolute mode
Well, there's code in Octolapse for this (position+position state+extruder tracking). I've been thinking of splitting it of into a separate plugin for other reasons (reuse).
However, Homing automatically is a problem since the printer might run into something (a non-removed print or something). Running it before the print starts is a really good idea that you suggested (most start gcode does this), but some folks do NOT do this for various reasons. Octolapse requires a home command, and I've fielded support requests where users manually home their prints and run gcode with no home. I actually added a pseudo G28 O command that will tell Octolapse that the current position is the home position to support these situations, though the solution is still in flux.
Anyway, this is a really interesting idea that maybe deserves its own thread? I honestly think this could eventually be a bundled plugin since so many are reinventing the wheel to get an accurate position/axis mode, etc. The 'Display layer progress' plugin immediately comes to mind, as well as the exclude region plugin. I know DisplayLayerProgress has some issues with G91.
The Octolapse code definitely needs improvement/cleanup as well as more gcode implementation (only a small subset is supported), but it is the most advanced position/state tracking code I've seen in a plugin. We should discuss more.
Created this Development thread and copied my posts over. Feel free to do the same with yours.
I think #2 would address my primary concerns (& likely those of many others). Reading the comments, it seems this feature/option does not exist. I think a check box option of "Prevent Manual Z-Axis Moves Below [##]" would be awesome. A manual move to Z-1 may be needed to adjust Z, so it could be good to let users change the max negative Z value. The option could go in OctoPrint Settings > Printer Profiles > Print bed & build volume" tab?
On second thought - maybe this would be easier:
If the check box is on the "Control" tab where the XYZ moves are done, it could be "Prevent Z move < 0" and a custom ## would not be needed. OR it could also be put in the left column (like "Send Custom GCode).
I appreciate you comments already. I'm not familiar with feature development, so I welcome any additional thoughts.
Based upon the comments by FormerLurker (who would know what's what), the feature appears to be problematic for a working solution across-the-board. There are different firmwares and at the moment, none of them save and report back the current state of the motor modes for X/Y/Z and extrusion.
That said, I would guess that a work-around would be to create a plugin which memorizes and exposes this information in a simple API could be sufficient. It would be nice to add to this the injection of a snippet variable or two for use in the Gcode scripts which OctoPrint maintains.
I'm not exactly how sure that would be used for the control jog buttons themselves. It feels like to me that editing the OctoPrint code itself seems like the most straight-forward method of adding the safety mechanism. It would also be possible using jQuery in the plugin to override the default up/down button binding so that two new methods be called which wrap their original respective functions (using the now-available information, as cached).