I've been having lots of troubles with my plugin, Octolapse, when it comes to axis modes (relative/absolute). For XYZ and E axis modes I currently have three options:
Require an Explicit Command (g90/g91/m82/m83)
Default to Absolute
Default to Relative
Option 1 is the default setting for all printer profiles currently due to my ignorance and caution. Lots of slicer gcode doesn't contain either G90/G91 or M82/M83, and seems to assume the printer will be in absolute coordinates. Octolapse decides not to interfere if it can't detect the axis mode in this case, so no snapshots are taken and the user is left confused, and rightly so.
I have a few questions that I hope someone can answer:
Do any printers (including deltas) default to 'relative' mode for either XYZ or E axes? If not, one of my options could go away.
Assume I have a gcode file sliced with Absolute XYZ and E coordinates, but with no G90 or M82 command. If I sent an G91 (xyz relative) or M83 (e relative) command manually to a printer, then started a new print from this file with OctoPrint, would the printer 'reset' to absolute coordinates at the start, or would it still remain in relative mode and go haywire?
Is your answer to #2 true for all printers?
If your axis mode is incorrect, are there printers that will try to move out-of-bounds and/or crash into the bed? My Prusa seems to prevent moving out of bounds (at least in the XY plane, not sure about Z since I don't have the guts to try it out), but I'm not sure if this is true of all printers.
I would REALLY like to fix this problem since lots of people install Octolapse but don't understand how to configure it, and configuring it is very difficult if one is a beginner! Setting the default axis mode to Absolute would eliminate this problem for many printers, but I want to make sure it doesn't mess up printers/prints.
I'm not aware of any off the shelf units, but there might be firmware variants out there that default to relative, so I'd stay cautious.
Yes, it would go haywire.
All that I know of. Firmware doesn't know if a line it received comes from the user or from a print job being streamed to it, there's nothing separating one from the other. Some variants support specific gcode commands to signal "a print job is starting here" to the printer (which you then can make party of the start code in the slicer) and those might also cause things like resetting to absolute mode, but there's no standard for them and they do far seen to be more of a rarity.
Yes, there are a ton of firmwares out there without software endstops enabled (and without endstops on both ends or intelligent stepper drivers), so more or less fatal print head movements like this are indeed a real concern.
I recently had a ticket opened where the "gcode viewer was going nuts", courtesy of a start code modified by the user that switched to relative mode for some preprint adjustments but didn't switch back, causing all coordinates to be interpreted relatively. Thankfully they didn't try to print that. In any case, it was fairly clear what was happening there since the first layer already went way way past the build plate.
I'm wondering if you could somehow look at the resulting moves of the first lines in the code and determine whether they are relative or absolute based on the coordinates in some way. Like adding them up and if they go past the bounds they are sure to be relative. And/or just prepend a switch to absolute by default even if you don't find that in the gcode. Just thinking aloud here.
That's exactly what I was afraid of, and why I implemented my solution in the most paranoid way possible . At least the effort wasn't wasted!
And/or just prepend a switch to absolute by default even if you don't find that in the gcode.
I too have thought about implementing some kind of pre-processor that reads the current gcode and attempts to discover these settings. Some kind of 'Slicer setting extractor' plugin would be really nice. I've been thinking of separating my gcode parser and extruder/position detection from my plugin, which would probably be useful here.
I've also thought about adding some kind of configuration wizard or at least some on-the-fly error detection/suggestion mechanism. I'd love to hear any other ideas, since there has to be a way to make this easier without being too risky (defaulting to absolute/relative coordinates).
Is there some way to query all/some printers to get the current axis mode for XYZ and/or E? That would be the next best case, but I'm guessing the answer here is also no
Yep, the answer is sadly no. A lot of the settings (coordinate mode, fan speed, feedrate and flowrate override, selected tool, ...) are pretty much write only values on most firmwares (Repetier being the exception here, which at least produces some parseable acknowledge output for some of those, but afaik also not for the coordinate mode). The host can set them, but there's no way to query them.
Welcome to one of the reasons for all those grey hairs on my head
. At least the effort wasn't wasted!