Z Offset plugin needs testers

[ahoeben 1,886]

By popular demand, I have created a plugin which adds a Z Offset setting to the custom print settings:
https://github.com/fieldOfView/ZOffsetPlugin

 

The easiest way to install this plugin is to download this file: http://files.fieldofview.com/temp/ZOffsetPlugin.curaplugin

 

Once downloaded, drop it onto the Cura window, and restart Cura. The Z Offset setting should then be available when you search for it using the search field.

Under the hood, the plugin uses a similar gcode snippet like this:
 

...
;Put printing message on LCD screen
M117 Printing...
(start gcode snippet ends here)
;LAYER_COUNT:399
G0 Z0.100000 ;go to Z Offset
G92 Z0 ;Z Offset is now considered 0
;LAYER:0
(first layer starts here)
M107
...

 

I am very much open to suggestions on better techniques (and must admit I have not had time to test it with an actual printer), but I don't know what works best.

 

If the plugin works, I'll do my best to have it available in the Plugin Browser for easier installation by the time that the final version of 3.2 launches.

Edited February 1, 2018 by ahoeben

[ChrisRiddell 13]

I'll give this a test tomorrow,

 

One thing does this move happen after the head has moved away from the priming area if not you will want to move the X for UM's or the nozzle with smash the bed clip this is what I use when printing in PETG.

G1 X40 Z0.05 F4000 ;Z Offset Hack, also move the X to not smash the bed clip
G92 Z0 ;reset zereo for Z Offset Hack

 

[ahoeben 1,886]

Good point @ChrisRiddell. The plugin currently does not take that into account, but I will see what I can do about that in a generic or customisable way.

[ChrisRiddell 13]

You could insert the snippet after the first line of skirt/brim gcode that way the head has already moved away from the prime area and has only done a small amount of movement on the bed.

 

But that would not work if skirt or brim is off.

 

anther way would be to loop over the whole gcode output and change the Z values but that would be really slow to process? for large-ish prints 

Edited February 1, 2018 by ChrisRiddell

[tinkergnome 926]

2 hours ago, ahoeben said:

I am very much open to suggestions on better techniques (and must admit I have not had time to test it with an actual printer), but I don't know what works best.

 

I'm not that convinced about the actual move of the z-axis to the zero coordinate...

Would it be possible to search the gcode for the first z-move (after homing with G28)?

Than add the offset to the found value (G92) and repeat the move (i do the something similiar with a customized start code at the moment).

 

...
G0 Zxx.xxxx  ;the original line (first found z move after the homing)

;inserted by the plugin
G92 Z[xx.xxx - offset]  ;add the offset to the current position
G0 Zxx.xxxx  ;repeat the original move (the same effect as a relative move by the offset value)

;rest of the gcode starts here
...

 

[ahoeben 1,886]

Yes, that should be possible, though it will take some tinkering.

[gr5 2,094]

1 hour ago, tinkergnome said:

Would it be possible to search the gcode for the first z-move (after homing with G28)?

This.  Please do it tinker's way.  That way you don't have to worry about bed clips and making blobs in the wrong spot.  And as a bonus you learn more python maybe?

 

Also people are going to want positive and negative offsets and tinker's method works for both positive and negative offsets unlike your original design which always does G92 Zxxx.xxx where xxx.xxx was always zero - now xxx.xxx can be positive or negative values and can be the current position if offest is zero.

 

[ahoeben 1,886]

14 minutes ago, gr5 said:

 And as a bonus you learn more python

 

[tinkergnome 926]

@ahoeben one observation: if you switch between printers, the offset setting is duplicated to the end of the panel.

I assume this has something to do with the 'naughty' line?

 

 

[ChrisRiddell 13]

Checked it out and yes it will smash the bed clip as it is now.

 

I do like @tinkergnome idea, would be interesting to see if that method could be implement.

Edited February 1, 2018 by ChrisRiddell

[ahoeben 1,886]

I have just uploaded a new version of the plugin for testing:

http://files.fieldofview.com/temp/ZOffsetPlugin.curaplugin

 

The Z Offset is now applied to the first Z move in the first layer, like @tinkergnome suggested. This should prevent any collisions with clips, and should properly allow a negative offset (up to the initial layer height value).

 

I still have to track down the cause of the "double setting" after switchting machines. I am jumping through hoops to add a setting from within a plugin (instead of from withing a printer definition as usual), and this seems to be somewhat glitchy. But the Z Offset functionality should now be... functional.

Edited February 2, 2018 by ahoeben

[ahoeben 1,886]

The "double setting" problem is fixed now:

http://files.fieldofview.com/temp/ZOffsetPlugin.curaplugin

 

I have submitted the plugin to be included in the Plugin Browser for Cura 3.2.

 

PS: I did not learn more Python, but I did get some practice in hacking the innards of Cura.

Edited February 2, 2018 by ahoeben
(wisecrack)

[tinkergnome 926]

2 hours ago, ahoeben said:

I did not learn more Python, but I did get some practice in hacking the innards of Cura.

 

Awesome! That means you can teach us more of this stuff soon...

[gr5 2,094]

2 hours ago, ahoeben said:

he "double setting" problem is fixed now:

http://files.fieldofview.com/temp/ZOffsetPlugin.curaplugin

Link doesn't work for me.  Maybe it's an illegal extension - maybe you need to zip it up or tell your web server to allow files with the extension ".curaplugin".

 

Or better - why not put it on github??

 

[tinkergnome 926]

16 minutes ago, gr5 said:

Link doesn't work for me.

 

@gr5 just remove the superseding point at the end of the url:

 

http://files.fieldofview.com/temp/ZOffsetPlugin.curaplugin

 

Manually copying to the plugin directory works too, the github link is in the first post.

Edited February 2, 2018 by tinkergnome

[ctbeke 133]

@ahoeben we can put the plugin in the browser any time, just give us a ping

[ahoeben 1,886]

I've already sent a friendly mail to plugins@ultimaker.com (as per the wiki). How many hops does it take until that lands on your desks?

 

Note to the others: it will take until the next release of Cura 3.2 for the plugin to show up in the browser (along with the currently missing OctoPrintPlugin), due to a mishap in the beta regarding API compatibility.

[ctbeke 133]

Should be a direct line to @Msuurmond?

 

3.2 release is gonna be very soon!

[Link 34]

will this work with the Ultigcode version of gcode ?

[ahoeben 1,886]

I would not know why it would not work with UltiGcode, or even Griffin (UM3)

[Msuurmond 28]

The mail goes directly to me and our testers. You can expect it to be live Monday or Tuesday.

[tinkergnome 926]

2 hours ago, Link said:

will this work with the Ultigcode version of gcode ?

 

Well.... test it!

(i have... and it works)

[ChrisRiddell 13]

Just found some time to test this used latest from GitHub works great.

[Msuurmond 28]

This plugin is also available in the plugin browser, thank you @ahoeben

Edited February 6, 2018 by Msuurmond

[jens3 10]

I was just trying this plugin with Cura 3.2.1. The z offset field shows up, I can enter a value (although there is a very limited negative range) but the resulting first layer print height is unchanged. There appears to be no modification to the gcode file that is generated for the print.

Is there anything that I could have possibly screwed up in the install or with my custom pre-amble gcode ?