Resetting axis positions
-
This is probably a stupid question, but I cannot seem to find a good answer, so here goes.
Cura is using G92 Zxx to adjust the height off the bed (it's an add-on), which is pretty useful for printing with PETG. Unfortunately, this leaves the printer in this adjusted axis position state. Notionally I ought to be able to use G92 to reset at the end of the print, except that that doesn't work for RepRap.
So, what's the best way to reset my Z axis to reality after a Cura print?
Thanks!
Rob
-
I am not sure if you have reviewed or not, but I use this link often to find what gcode I need.
https://reprap.org/wiki/G-code
Not sure what you mean. G90 returns the unit to absolute mode where G91 is relative. if you need to reset what position you are at G92 Z0 for example will tell the controller the current z position is 0.
-
@bpislife Thanks; I am familiar with that list. My understanding is that G92 redefines the axis positions, and G90 is working in terms of that redefined set of axis values.
I'm having a hard time working out how to reset the axis values at the end of a print, which is when I need to do it, because when I use Slic3r to generate gcode, it does the much more sane thing and simply adjusts the Z values used in the plan rather than this G92 trick, so leaving the axis adjusted will result in printing higher than intended.
I'd also like to not have to re-home the Z axis or reset the board. I'm sure there's a simple answer to this, I just haven't figured it out.
Railcore II 300XL w/ Duet 3 & RRF 3.5rc4, Makerbot R2X w/ Duet 2 WiFi & RRF 3.4
-
If you have a "G92 Z0.2" at the beginning of your gcode file then edit your gcode file to have the opposite effect at the end. So if your print stops at a z height of say 40.5mm then at the end of the gcode file add a "G92 Z40.3". It will get you back without homing.
Kind of a pain to keep editing like that for each file, maybe someone knows of a script and can create one to do it in Cura automatically?
-
@timcurtis67 Thanks. I'm really trying to avoid this solution for exactly the reason that you say -- that it's going to mean manually editing gcode files each and every time I generate one from Cura. A script to do this would also be an option, of course, but really all I need is a way to reset the axis changes back to "0". This can be done on some platforms with a "G92" with no other parameters, just not on RepRap.
I've looked at the gcodeutils for generating arc gcodes in the past. It doesn't have an option to translate in the Z, but probably it could be done with minor modification w/out too much trouble. This just doesn't seem like something that needs a script solution?
Thanks all for the discussion so far...
-
don't adjust the height in the slicer but use babystepping!
-
You could also use work offsets instead of Cura to adjust your first layer.
Example,
If you always print PEG-T at say .1 higher off the bed then set that offset in your G54. Then have the G54 at the start of your print either by having Cura write it in at the very beginning of the program or using a Macro to add the G54 plus run the print file you want. Then go back to the machine work offset (G53) at the end of the print.Maybe David will chime in here,
-
I'm curious to know why you don't want to simply home the printer before the next print in order to reset the axis positions. You can add the homing command to the slicer start gcode so it doesn't involve any extra step. Given that for the next print, the print head has move to the first layer height, it really only take a fraction of a second longer to move to Z home first. In fact, if you use a heated bed, then you can home the printer while the bed is heating so it takes no time at all. Or have I misunderstood what it you are trying to achieve?
Edit. Or is this a Delta printer or one that homes to Z max?
-
@deckingman Good question. I home to Z min (BLtouch). In my current config, I tend to clear my bed compensation at the same time that I re-home the Z, then redo compensation (the grid). So it is time consuming, but I do it infrequently because neither seems to really get out of wack.
I agree that if I were only re-homing Z that it wouldn't take particularly long to do, assuming I didn't clear the bed compensation as part of that. So, this is an option.
-
@whosrdaddy Thanks! This is the least invasive suggestion so far and can be reversed at end of print. Out with the Cure plugin, can just do this in the printer-specific gcode start/end.
-
Looks you've found the solution by using baby stepping but for info, I'm fairly sure that simply homing Z will not affect the bed compensation (although I don't use any form of bed compensation myself so can't be 100% sure). It's generally good practice to home all at the start of every print though as anything could happen in between prints.
-
@deckingman I understand your point, but either I believe that things are staying mostly put (which evidence indicates they are), or I probably need to redo the whole process...
It's a D-Bot with three lead screws, two in the front being driven by the Z stepper controller and one in the back being driven by the second extruder controller. Bed is a thin plate on standard cantilever, attached in the back, using 4 wheels per side, glass on top. I'm just as likely to have just one screw do something funny as the whole bed move... which definitely does happen when I power down.
At some point I'll lock things down a little more solidly and/or replace that low-end bed, at which point maybe I don't need the compensation, but for the moment I think what I'm doing is rational :)?
-
@paralepsis said in Resetting axis positions:
@deckingman I understand your point, but either I believe that things are staying mostly put (which evidence indicates they are), or I probably need to redo the whole process...
It's a D-Bot with three lead screws, two in the front being driven by the Z stepper controller and one in the back being driven by the second extruder controller. Bed is a thin plate on standard cantilever, attached in the back, using 4 wheels per side, glass on top. I'm just as likely to have just one screw do something funny as the whole bed move... which definitely does happen when I power down.
At some point I'll lock things down a little more solidly and/or replace that low-end bed, at which point maybe I don't need the compensation, but for the moment I think what I'm doing is rational :)?
Yes, understood. The upside of having 3 driven screws is that you can automatically level the bed. The downside is that whenever you cycle the power, the motors will jump to the nearest whole step which might be forward it backward so they can get out of sync, which means that you have to redo the levelling whenever you turn the printer on. For that reason, you might consider using a single motor and continuous belt as and when you get around to upgrading. Just a thought..
