[Feature Request]: Add Z-offset filament override

[bortoni]

Version

PrusaSlicer-2.1.0-alpha1

Request

Since Filament override was added for retraction, it would be very useful to also add Z-offset.
This is currently only in Printer Settings.

PETG for example benefits greatly from being printed "a bit higher" off the bed vs PLA.

[langph]

Agreed, and it would be the best to add the delta, not the actual offset stored in the printer for each steel sheet.

[pboucher14]

That would be a good feature to add. Really usefull for PETG

[mgg4]

I agree completely. +1 for including this. I'm currently using PrusaSlicer 2.2.0, and this feature would be very much appreciated.

[Pelado-Mat]

+1.

Agreed, and it would be the best to add the delta, not the actual offset stored in the printer for each steel sheet.
The delta would be even better.

[murphydan]

I was hoping something like this already existed for PETG. I add my vote!

[userosos]

What about it? I cant see it the new build with alpha version. I think that in the menu settings need add all of them settings from Print Settings and Printer Settings. It will be good!

[skorokithakis]

There already is a "Z offset" setting in the printer tab, can we get a "Z offset" filament override? This ticket has been open for more than a year, it's a very useful feature that seems lilke it'd be simple and worthwhile to add.

[romanlucas]

+1

[DatenThielt]

Also would like to see this feature, I have 3 different PLA suppliers and one of them requires more squish than the others, as well as PETG liking a bit more height than PLA. Easier to set it here than on the printer and "forgetting" the last height set 👍

[JBFUK]

+2

[JAYTEEAU]

+1
New to Prusa Slicer. This would be very useful indeed. Different materials would benefit greatly from this. IMO a perfect Live Z shouldn't need to be noted and changed per filament requirements

[TheAtelier]

+1
This ticket has been open for almost 2 years now.

[krossdal]

+1

[bartbergman]

+1

[1activegeek]

Coming to add a +1

@pboucher14 I see your reference here to some code - but I don't know much about PrusaSlicer code, so I'm not sure if that is just a skeleton fro the option or if that is the full bit of code needed for a pull request?

[Alpacad]

+1

Coming from PrusaSlicer-2.4.0-alpha1 and found this while searching for the same feature requested idea.
Strange that this is still open after 2 years, having Z Offset in Filament Overrides would be a time saver when switching repeatedly from PLA to PETG and TPU.
Needless to say the times I forgot to adjust it in Printer Settings.

[skorokithakis]

Good thing you commented, I was trying to find this comment for ages but failed. A workaround for this (for people who have autoleveling) that I do is to send M851 Z<offset> to get my printer leveling at a different height.

[ardichoke]

Came here from the above issue that got marked as a duplicate. I'd also love to see this, or even better, if you could arbitrarily add any print settings to a filament profile with an override (I think ideamaker does something like this).

As a workaround, adding something like this to the filament start g-code has worked for me:

G0 Z0.2
G92 Z0.0

This would add a 0.2mm positive Z offset to whatever the normal offset is.

[Alpacad]

@skorokithakis as you say, this works for printers with auto bed levelling, to this day a lot of printers don't have a levelling probe as it is easier to setup.

@ardichoke this looks like a good compromise, but the custom filament g-code is inserted after any printer start g-code, sometimes this gives petg enough time to create a mess while priming the nozzle before starting to print.

[skorokithakis]

Actually, @ardichoke's solution is better than mine, nice!

[userosos]

Came here from the above issue that got marked as a duplicate. I'd also love to see this, or even better, if you could arbitrarily add any print settings to a filament profile with an override (I think ideamaker does something like this).

As a workaround, adding something like this to the filament start g-code has worked for me:

G0 Z0.2
G92 Z0.0

This would add a 0.2mm positive Z offset to whatever the normal offset is.

Hi! What if i need Z offset set to -0.1 mm?

[Alpacad]

In case it can be useful, I modified my filament start gcode.
@ardichoke gcode works very well, but I find that the use of placeholders and macros describes better the process of adding an offset. It makes it more "readable".

So, I edidted my custom filament gcode like this:
; PETG Z offset
G1 Z{first_layer_height + 0.2} ; move nozzle to offset
G92 Z[first_layer_height] ; set current Z position as first layer height

Similarly to @userosos request, the same could be done for negative offsets:
; Negative Z offset
G1 Z{first_layer_height - 0.1} ; move nozzle to offset
G92 Z[first_layer_height] ; set current Z position as first layer height
This one should be even more simple than the previous method.

[jremen]

+1

This feature is tremendously needed for PETG and TPU as well.

[dougshell]

This would be helpful for ASA as well due to the increased bed temp

[tommylux]

In case it can be useful, I modified my filament start gcode. @ardichoke gcode works very well, but I find that the use of placeholders and macros describes better the process of adding an offset. It makes it more "readable".

So, I edidted my custom filament gcode like this: ; PETG Z offset G1 Z{first_layer_height + 0.2} ; move nozzle to offset G92 Z[first_layer_height] ; set current Z position as first layer height

Neat workaround, but if you're like me who has multi extruder printer, the Filament Start G-Code is executed at every tool change. I need to ensure that it is only executed once (on the first layer. Tried the following logic:
{if layer_num ==0} G1 Z{first_layer_height + 0.2} ; move nozzle to offset G92 Z[first_layer_height] ; set current Z position as first layer height {else} {endif}
But it looks like layer_num is available in the current version of 2.5.0

A new filament override z offset setting would be nice.

[evilC]

+1 vote for this feature.
Yeah you could do it via gcode, but that's not exactly great UX

[stefanct]

@rtyr I am tagging you because you are the only contributor having some interaction with this bug.
can you give us some insights on any prusa-internal discussion regarding this issue, if any? are there any implementation peculiarities that would make it hard to add?