Jump to content

Bug: Z-axis offset incrementing


Recommended Posts

Posted · Bug: Z-axis offset incrementing


I noticed when I print a print with Z-axis offset a 2nd time the offset is incremented. I have to reset the printer for a 2nd print (or change the gcode manually before I put it on the printer).

Then I had a look at the gcode. There was no G92 in the end. G92.2 would be the correct code to erase all offsets BUT it's not implemented in most firmwares* so it must be done with a line at the gcode file's end like this:

G92 <real position>

where <real position> is the last Z value used for a move + offset

I'm using Cura 3.6 AppImage with the Z offset plugin.

I know the G92 command and it's subcommands from CNC-milling where you usually set it by hand after measuring before you start the program.

It's in general a good idea to use G92 (vs. slic3r, which changes all the Z values) because I can modify it quick on any computer near the printer with an editor and do not need to walk (30m through the rain) to go to the computer where cura runs (ssh -Y is not an option as cura requires OpenGL).


* see https://reprap.org/wiki/G-code#G92.x:_Reset_Coordinate_System_Offsets_.28CNC_specific.29




  • Link to post
    Share on other sites

    Posted (edited) · Bug: Z-axis offset incrementing

    I've a workaround now and I like it.

    I stop using Z-offsets in Cura and slic3r. I took them out from all my gcodes generated by Cura with an editor. The slic3r gcodes have to be made new.

    What I do instead:

    I made a file "Z-offset.gcode". It contains only one line:

    G92 Z0

    My printer shows absolute Z values in the display (Repetier firmware). So I can just jog to the Z position I want as offset an then "print" the Z-offset file. That keep's the offset until I use it again or switch the printer off or reset it.

    The axis can be homed afterwards the offset stays.


    (Take care about the 0.025mm Steps! My Display shows the Z values in .1 Steps but one button press moves .025mm so I have to stop pushing it at the first time 1.0 shows up when I jog up and press another 3 times when it shows up when I jog down and want 1.000 offset. Just imagine it goes 0.900 -> 0.925 -> 0.950 -> 0.975 -> 1.000 or down 1.100 -> 1.075 -> 1.050 -> 1.025 -> 1.000 )


    I think that's cool:

    • It's more flexible as slic3r's method, where you've to create the file new if you need a new offset or write a script to change all Z values in gcode.
    • It's safer as Cura's method can be because if I (interrupt (a Cura print with offset) without reseting the printer) it would not be taken out and the next print trial would get a double offset, even if it would/will be fixed as supposed.
    • It's fast when at the printer and I change something with the bed (Glass, Tape, Plywood subconstruction humidity change...).
    • It's independent: No need to take the SD back to the computer. No plugin needed.

    Another hint:

    Make the SD-Card empty and then put the Z-offset.gcode file on it. This way you have it in the first line in the list of printable files. My Printer seems to have no collation. What's in the FAT first comes first. If your's sorts by alphabet or whatever use filename suiting for you.


    So Cura developers, documenters, tutorial writers:

    If you fix the Z-offset Plugin or in China a bag of rice tips over. I don't care. Well, it should be done - makes it clean.

    You can use my idea in Tutorials and documentations. Makes life more easy, especially if you have a cheap printer which needs to be calibrated more often. Also moving my Z-Axis switch sucks. It just has long holes. If I would have to adjust something with long holes and just want to move it some hundreds of a mm at a big machine I use a plastic hammer, but here even this is not really an option.

    Edited by Das_Sams
    missing word
  • Link to post
    Share on other sites

    Posted · Bug: Z-axis offset incrementing

    Interesting, what firmware r u using? As far as I know G92 will be "reset" once homed.... so unless you print second one without homing.... the z offest will be gone...

  • Link to post
    Share on other sites

    Posted · Bug: Z-axis offset incrementing

    What is your start gcode?

    G28 ;Home
    G1 Z15.0 F6000 ;Move the platform down 15mm
    ;Prime the extruder
    G92 E0
    G1 F200 E3
    G92 E0

    Does it include a G92 command?


    Yes, but it only affects the extruder.

    Thanks for the plugin and for the bug. Without the plugin I would have used slic3r and the bug made me learn. I don't know how long it would have taken for me to get the idea to adopt the G92 from the mill to the 3d printer otherwise. BTW. I tried G92.2 on my printer but it was ignored. If you have an account at the reprap wiki mentioned above, please update repetier from unknown to no.



    Interesting, what firmware r u using?


    It's the default FW on an Anet A8 (clone). I guess it's repetier as repetier host for windoze was supplied on a CD.


    As far as I know G92 will be "reset" once homed.... so unless you print second one without homing.... the z offest will be gone...

    No, as you see. The printer is homed at the beginning of every print. Also it's not desirable to loose all the offsets with homing. There are several reasons for homing, like lost steps for various reasons (collision, emergency stop with uncontrolled deceleration) or complete position loss on a blown fuse on the 3~ (G-Code is not only for 3d printers). In lot's of these cases I don't want to measure the position of my machine vice in all three axes again. On the 3d Printer you loose steps at the end of any print cause the steppers don't hold against ripping 300cm² PLA off the bed.


    BTW.: The offset could be done in the start code with G92 -<offset> after homing BUT CAVEAT: The home position might be not 0.


    #<_offset> = 1.225
    G0 Z0
    G92 [0-<_offset>]

    would be better - in the hope there is no collision when doing this move. Well if that would be the case you'd have to do something manual anyways.


    For the End code there would be something like

    G0 Z [240-<_offset>] ; highest position officially supported by Anet A8 is 240 see note
    G92 Z 240

    In this specific case we would get a collision which would need a realignment of both Z axis motors as the A8 does not have the total 240mm space the vendors claim. But that's a little off topic - just in case someone copies here.

    A great drawback is that it's a really time consuming thing to go up to the maximum and down at the end and begin of any program.

    In this case we would have an variable for the offset. Well. I have not tested it and I've no idea which printer firmwares have vars implemented. If not they have to be calculated by the plugin and the values put in the code.


    It's all painfull. I will stay with my workaround. For beginners or printers w/o display it's still needed.

    goede succes

  • Link to post
    Share on other sites

    Posted · Bug: Z-axis offset incrementing

    The G28 (home) should by its definition revert any offset set with G92, so I don't quite understand why the z axis offset is incremental for you.

  • Link to post
    Share on other sites

    Posted · Bug: Z-axis offset incrementing

    The definition does not imply this. Neither RepRap G-Code reference nor LinuxCNC G-Code reference nor Wikipedia mention any correlation of G28 and G92. And believe me, on a CNC-mill it would cause trouble. Having to rehome an axis does not necessary move your vice or workpiece on the table. Telling the machine were the work piece is on the table is what G92 was made for. What you store with G92 can be the result of an hour of measuring and sometimes even not be recovered after something is milled.

    I think it'd be a bad idea to change this in printers' firmwares. Someone could take a modern (fast enough) CNC-mill and put an extruder in a chuck. Don't brake this. We love standards.

    So the plugin has to deal with that. And this means the print file has to set the offset back at the end. Of cause this is not ideal as someone might interrupt the print. As we cannot change that, doing the G92 manual is better. People should be encouraged to do so.

    If you're to lazy to jog and always have the same offset, then a file with

    G28 X Y ; home X and Z
    G0 X-35 ; Change the value to your needs. Homing Z shouldn't crash the extruder on you bed.
    G28 Z   ; home Z
    G92 -<_offset> ; where <_offset> is your desired offset. If 0 is not your home position change
                   ; analogously.

    You can have both files on the SD.


    Today I got a new glass plate from China. I was printing on a small piece of junk glass before. I already had the next print which would have been to big for the junk glass on the printer. Well, when the print from yesterday was done I measured the new glass thickness, calculated the offset, swapped the glass, jogged to the calculated new offset, ran my one liner and started the next print. This is quick. No need to unmount the SD, mount it on the Desktop, change the file in an editor or worse reslice it, unmount the SD, mount it on the printer... Someone could just spontaneously decide to use painters tape (+0.1mm) or something else or the plywood carriage under the bed warps... and quickly need a new offset.


  • Link to post
    Share on other sites

    Posted · Bug: Z-axis offset incrementing

    Anyways, if there are printers out there which reset G92 when doing G28 it doesn't hurt to reset the offset made in the beginning at the end of the gcode.

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
      • Ultimaker Cura 5.6 stable released
        Cura now supports Method series printers!
        A year after the merger of Ultimaker and MakerBotQQ, we have unlocked the ability for users of our Method series printers to slice files using UltiMaker Cura. As of this release, users can find profiles for our Method and Method XL printers, as well as material profiles for ABS-R, ABS-CF, and RapidRinse. Meaning it’s now possible to use either Cura or the existing cloud-slicing software CloudPrint when printing with these printers or materials
        • 6 replies
    • Create New...