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...
I am the developer of the Z Offset plugin. @Das_Sams, thanks for the feedback about my plugin. What is your start gcode? Does it include a G92 command?
QuoteWhat 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
QuoteDoes 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.
QuoteInteresting, 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.
Quote
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.
So
#<_offset> = 1.225
G28
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
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.
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.
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.
Recommended Posts
Das_Sams 0
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:
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_Samsmissing word
Link to post
Share on other sites