Page MenuHomeAleph Objects Inc

Feature Request: Z Offset Value
Open, LowPublic

Description

Requests for a Z offset change in Cura 2 have been reported on the forum.

Request:

Box to enter a Z offset for slight tweaking for customer ease of use. This prevents requiring to connect via console or LCD to adjust Z offset

Event Timeline

karrad created this task.Nov 28 2017, 7:17 AM
alexei assigned this task to efilenko.Nov 28 2017, 7:20 AM
alexei changed the edit policy from "Custom Policy" to "Restricted Project (Project)".
alexei added subscribers: efilenko, victor_larchenko, alexei.
alexei moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 28 2017, 9:40 AM

@alexei @karrad @victor_larchenko : Which command should we send via console for modifying Z offset?

@efilenko The gcode command through console is M851 Z<value>

"M851 Z-1.3" for a negative 1.3mm offset

This comment was removed by efilenko.
This comment was removed by efilenko.
efilenko added a comment.EditedNov 28 2017, 11:43 AM

TODO Summary:
TextFiled +checkbox for saving to flash memory (default is don't save it, keep it in Cura memory)
M851 <value> -- set Z-offset,
M500 --save Z-offset to flash memory,
M851 -- report current Z-offset from flash memory

Example:
"M851 Z-1.3" for a negative 1.3mm offset

ScottWell1 added a subscriber: ScottWell1.EditedNov 28 2017, 1:35 PM

Just a comment on this....

Adding UI elements to change M851 isn't a great solution. The desire is to have an "additive" or "relative" Z-offset in the SLICER (as was available in Legacy Cura), which alters the sliced gcode rather than the firmware value.

Imagine having multiple printers (same model) with slightly different M851 values due differences in manufacture. Now you're slicing an object, and want a slightly different Z-offset due to geometry or material. In legacy Cura, an additional offset (+/-) could be specified which was added to every Z coordinate during slicing. That gcode can now be printed on either printer -- as the offset in Cura is "additional" (relative) to the machine's firmware Z-offset.

The desire isn't just an easy way to change M851 without going to console. It is a way to slightly tweak certain profiles (usually for certain materials) such that the Gcode produced has slightly lower (or higher) Z-coordinates, such that the minor change in offset is specific to that sliced gcode (rather than making a global change to the printer).

What is being asked is to bring back the legacy Cura behavior, where the Z-offset in Cura affects the Z coordinates in the sliced gcode. That way a small variation (like -0.05 or -0.10mm) can be specified during slicing, causing a RELATIVE z-offset adjustment on any target printer. (Note: There was some discussion of this in upstream Cura, and it appears the decision there was to omit z-offset, and instead add a "first layer flow %" to produce similar results.)

@ScottWell1 @alexei : 1) I can create UI for modifying Z-offset, but what should I call to modify G-Code? I tried find anything relevant in the code, still no clues.

  1. Which way do we want to proceed: with M851 command or Z-offset way in G-Code ?
ScottWell1 added a comment.EditedNov 30 2017, 6:33 PM

The customer request is a way to "slightly alter" Z offset of model in a given slice operation.

That is not handled well with M851. Customers would have to remember the "real" offset value, and then enter calculated values that incorporated their small change (usually +/- 0.15 or less, and different for different materials). A customer mistake here, entering too large a magnitude negative, would crash into the bed.

Legacy Cura included a Z-offset field, and added that value (+/-) to all Z coordinates in the output Gcode. If you specified first layer height of 0.40, and a z-offset of -0.05, then the resulting Gcode file would send Z to 0.35 for first layer --- no firmware change required. (This is what customers are used to having, and what was requested on forum.)

Upstream Cura2/3 devs discussed this and decided against adding the feature. They decided a "first layer flow %" was a better option for multiple reasons. It produces similar results in terms of adhesion, it can be per-extruder for multiple extruders (which M851 cannot), and there is way less chance of a customer damaging something -- they can't crash the head into the bed using a "first layer flow %" to increase/decrease first layer flow.

So my first choice: I agree with upstream devs that the Z-offset processing in legacy cura should NOT be added to Cura2/3, and instead a "first layer flow %" feature should be added to print Profiles. It satisfies the same need, can be per-extruder, and is safer for users. Add a "first layer flow %" modifier to the UI and slicer engine, or wait for upstream to incorporate it (which could be a long time). If users really want to adjust M851, which is global to all prints and potentially unsafe -- then point them to the console commands or LCD, but with instructions to minimize chance of damage.

My second choice: If you really want to give users control of Z-offset in Cura (like Legacy Cura, where it adds a user-specified value to all Z coordinates during slice), even though upstream has decided against it, then investigate whether this can be accomplished in a Cura2 Plugin. That should be possible, and eliminates the need to merge changes with future upstream releases, but I'm not an expert on the Plugin architecture so am not sure what is involved.

My last choice, which I would NOT recommend: Add a field in the UI for Z-offset. Add a function called at startup which initializes the value by reading an M851 response (if printer is connected, otherwise leave blank). Allow users to update the field, along with a "store in firmware" flag. Before first print line (whether via USB or to file), if the field has a value, output "M851 Z" followed by the user-specified value. If the user set the "store in firmware" flag, also output M500 to save current values. (NOTE: This is also dangerous, as the user may have made temporary changes to other firmware values -- and sending M500 will store those to memory along with the new M851 value). Did I mention that I don't recommend this approach?

@alexei Not clear, should I proceed with M851 option and config flashing enable way?

Is there a way to solicit wider discussion within AO on this? Do you have some kind of internal review board or process that looks at pros/cons of feature changes to decide on direction? Any of the options have costs (except perhaps just waiting for upstream to add a feature), and will be very visible to users. It would be good to have multiple experienced folks weigh in on the design decision before choosing one.

I can say that users are disappointed a feature they used a lot was removed/lost when moving from Cura to Cura2 (the Z-offset in Cura that changed Z-coordinates in slicing). Something needs to replace that, at some point. But I don't think access to M851 through the UI will fill that need, and may actually be dangerous for novice users.

Of course I'm just one user with one opinion.... And I don't have to write code or answer support calls, so it is easy for me to have an opinion. :-)

@alexei @tranter Please, clarify, should I proceed here with M851 ?

alexei added a comment.Dec 5 2017, 6:43 AM

@ScottWell1,
The discussion here is as wide as it gets.

@efilenko, @ScottWell1 :

Since the Zoffset is a characteristic of particular printer and we want the same g-code to be run on any printer, we should not modify the g-code.
Instead we should be able to modify Marlin's variables from Cura for those who really need it.

So we are really should go with this option:

Add a field in the UI for Z-offset.

Pretty much having a field for Z offset in USB Tab that one can change (we can set some limits there on how it can be changed)
And also having a button "Save Variables to Flash" which will call M500.

All of these options should be enabled only when "Enable Marlin parameters handling" option (that should be added to Cura General Preferences) is enabled
in order to prevent unexperienced user to change anything.

This will have an advantage for users without LCD on printer (Mini) to be able to finetune their Zoffset at least without the need to deal with G-codes.

Another button that worth to be added is "Restore Factory Settings" ( M502 and M500). Since Marlin is not good with updating parameters in flash with new subversion number. Example of the issue can be found here T1398

@alexei:,

I agree that M851 Z-offset is "a characteristic of a particular printer". In theory, it should be set for a given printer and not changed unless the printer geometry changes. That is precisely the reason the additive software Z-offset in Legacy Cura was valuable, and why users are disappointed it doesn't exist in Cura2.

The software z-offset in legacy Cura allowed minor tweaking (additive to printer's M851 value) for a particular slice. Example with Legacy Cura: User is slicing for ABS and wants more adhesion, so he specifies -0.10 for the software z-offset in Cura21 -- putting the model 0.10 closer to the bed for more squish. Next, the user slices for PETG and specifies +0.10 so it prints higher and doesn't stick too much. This accommodates different materials/models without changing the printer's Z-offset between prints (really important in a multi-user environment -- where we don't want each user changing M851 for their print!).

Most users don't want to change the printer's Z-offset between prints. They want to alter adhesion for specific models or materials, and that's what the software z-offset in legacy cura provided (by moving model up/down by 0.05-0.20mm, without changing printer z-offset). Something that provides that functionality (like the software z-offset in Cura21, or perhaps "first layer flow %" instead) needs to be provided in Cura2 or this request will keep coming from the user community.

Adding M851 to the UI is fine, but it really won't solve the issue (or satisfy the user request) that led to creation of this task.

@alexei What do you mean under USB Tab? Should I make on? Where do we want it?

Ok, USB Tab == Print Monitor

karrad added a comment.Dec 8 2017, 2:21 PM

@ScottWell1 We discussed this ticket today in our meeting, and believe we have a solution for both. As Z-Offset is used in Marlin to account for build variance, we would like to avoid any possible confusion between Cura/Marlin. We are going to leave this ticket open and as titled, and implement the easier way to update the offset through firmware.

We have opened T1484 which should allow for material specific compensation on the first layer, without the need to adjust Z offset. This setting will be able to be saved per material/profile, and should be easily customizable for the end user.

@karrad

That sounds great, particularly T1484. Thank you!

efilenko added a comment.EditedDec 13 2017, 7:37 PM

@alexei : Please, review proposed UI ( it is plugin, so we can disable it if desired ).

  1. What would be the functionality of "Save" button?
  2. Validation for Z-offset?

@alexei @karrad Under validation I mean boundaries and value type: lower boundary, upper boundary and value type: float, int etc

@efilenko

1.) The save function will send an M500 command to store the M851 Z(value) in the eeprom

@mcoronado

Can you provide efilenko : boundaries and value type: lower boundary, upper boundary and value type: float, int etc

@efilenko @karrad Please see the image below for alignment. Please feel free to reference Input values from previous elements in the Print Monitor.

My input.....

If this is intended to mirror functionality of LCD, then the field would need to be populated with printer's existing Z-offset when printer is connected. That would require sending M851 to printer, parsing response for existing value, and populating the input field with that value.

The typical user desire will be to change existing Z-offset by small amount (like +/- range of 0.05 to 0.15). If the field is not pre-populated from the firmware's current M851 response, then it would be up to the user to "know" (or find, via console and M851) their printer's current value. The user needs the current value to calculate the new value -- by adding/subtracting their desired delta.

The firmware defaults are -1.20 for Taz, and -1.38 for Mini. So a signed float value.

Typical use on a stock printer would be:

  • Increase magnitude very slightly (increasing too much risks bed damage). I would not recommend allowing a value smaller than -1.30 for Taz or -1.48 for Mini.
  • Decrease magnitude slightly. Users would be unlikely to need a value larger than -1.00 for Taz, or -1.18 for Mini.

Clicking "Save" would send printer "M851 Z" followed by field value. If the "save to flash" option is checked, that would be followed with a second command, "M500". (One concern here is that M500 saves ALL current values to EEPROM, and not just the value changed with M851. Not sure if user should get warning about this.)

This comment was removed by efilenko.
This comment was removed by efilenko.
karrad added a comment.EditedDec 19 2017, 7:29 AM

@efilenko We are showing this option is disabled by default, but still visible. Would it be possible to make it hidden until the customer activates it?

If not can we revert this until next release?

efilenko added a comment.EditedDec 19 2017, 9:57 AM

@karrad : UI is a plugin, you may disable it and restart Cura2. Go to Preferences/General and uncheck Z-Offset, than restart Cura2. Or I can make invisible TextField and Save button. Would you like this option?

I tested this and observed the following:

  1. The plugin constantly sends M851, 4 or more times per second. This creates an unacceptable amount of serial traffic, and it makes the Console unusable. It would probably be best if it somehow hooked an event such that it only issues M851 to retrieve current setting when printer connects.
  1. There is no error message when an out-of-bounds value is specified and "Save" is clicked. Can an error dialog be generated here?
  1. What are the value bounds? From my testing, the range appears to be -2.0 to 5.0. If a user enters anything smaller than -1.50, they will likely damage their bed. Is this acceptable? I strongly suggest limiting lower bound to -1.5. The only reason more would be needed (unless something is changing with Mini2) is if the user has made some modification to their printer -- and those users can be directed to console instead of UI.
  1. The preferences checkbox that enables/disables the feature does not get saved. If the preference checkbox is set to enable the feature, then Cura closed/opened, it resets to disabled. Is that intentional?
  1. The Z-offset is successfully set when an in-bounds value is specified and Save is clicked. It appears that M500 is always issued, whereas earlier discussion had indicated that would be optional (i.e., another checkbox to determine whether value was temporary or stored to memory with M500). Is always saving to EEPROM the desired behavior?

One more observation / question:

  1. The plugin operates for all printers. M851 sets the "probe-to-nozzle offset", and as such is really only applicable to printers with auto-leveling. (Not sure if M851 even has an effect if G29 isn't used?) Should this plugin only appear in UI for auto-leveling printer models?

@ScottWell1 @karrad @alexei :

  1. I don't have answer right away here, need some time to see what is possible here.
  2. 3) I can just prohibit entering wrong value into TextField, for now boundaries are -100.0 <= z_offset <= 100.0 on UI side (I don't know values on Firmware side). I can set any numbers as boundaries on the UI, please specify. You don't need a popup, you just would not be able enter wrong value just like now you cant enter 156.00, for instance.
  3. Yes, this is right behavior, can change it if required
  4. Yes, this is what we do now. When Save button pressed, Z-Offset from the TextField is save to EEPROM
  5. You can always disable plugin and restart Cura. Unfortunately, I don't have the answer on the M851 and G29 commands relation if any.

Another issue... Log is being filled with errors when using network printer device (i.e., Octoprint). This is partly due to the plugin trying to refresh M851 multiple times per second (mentioned as #1 above, also makes console unusable) and partly due to inability of plugin to directly communicate with the network device.

Example log entries:

2017-12-19 14:25:43,704 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:44,190 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:44,191 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:44,699 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:44,701 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:45,194 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:45,195 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:45,684 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:45,686 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:46,185 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:46,186 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:46,687 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:46,689 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:47,185 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:47,186 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:47,688 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:47,693 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:48,185 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:48,186 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:48,704 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:48,706 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:49,184 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:49,185 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:49,685 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device
2017-12-19 14:25:49,686 - WARNING - cura.PrinterOutputDevice._getZOffset [429]: _getZOffset is not implemented by this output device

@alexei @ScottWell1 @karrad : Currently Z-Offset is implemented only for USBPrinterDevice, get/set ZOffset functions are not simply there yet. And, someone, please, give me the boundaries for ZOffset, now I have -100.0 <= z-offset <= 100.0

Currently Z-Offset is implemented only for USBPrinterDevice, get/set ZOffset functions are not simply there yet.

Having these fields/buttons in the UI (and logging dozens of warnings in log) in situations where it doesn't function will cause user confusion. Can the plugin disable itself, so it doesn't display in UI and doesn't try to send M851 commands when:

  • The printer is not USB, or
  • The M851 is not relevant (i.e., a printer that doesn't have auto-level capability)

If that isn't possible, perhaps the Plugin could be disabled by default (i.e., plugin not active unless user manually goes to Preferences, Plugins and enables it)?

Regarding M851 value limits... This should really be different for different printer models *IF* you want to avoid users shooting themselves in the foot (and damaging their beds). In a previous post, I proposed -1.00 to -1.30 for Taz6, and -1.18 to -1.48 for Mini as "safe" values. (I don't have a Taz6 to test -- so am basing that range from firmware default.)

If you use a single range for all printers, it would need to encompass both of those ranges (i.e., -1.00 to -1.48). But that risks a Taz6 user setting a value intended for the Mini, and potentially crashing their nozzle into the PEI surface.

UI best practice would be to provide some feedback to user when value entered is "out of range". If not a pop-up, then at least change field background color to red, which would be consistent with rest of Cura2 UI.

@ScottWell1 : I already disabled plugin for now. Huge thank you for Z-Offset boundaries, I will use same range for all printers for now ( -1.00 to -1.30 ). @karrad @alexei may correct me if this is wrong.

@efilenko

I think the range needs to be -1.00 to -1.48 (please see my earlier message again). A minimum of -1.30 would not be small enough for the Mini.

The firmware default for Taz6 is -1.20, and for Mini it is -1.38. I recommend giving users a variation away from that default of +0.20 to -0.10. That would make the range for the Taz6 (-1.00 to -1.30) and the range for Mini (-1.18 to -1.48). (@karrad @alexei -- does that logic sound reasonable for determining upper/lower bounds?)

So if you intend to cover both printers with one range, it would be (-1.00 to -1.48).

@ScottWell1 @karrad @alexei:
Addressed

  1. The plugin constantly sends M851, 4 or more times per second. This creates an unacceptable amount

of serial traffic, and it makes the Console unusable. It would probably be best if it somehow hooked
an event such that it only issues M851 to retrieve current setting when printer connects.
DONE: We query firmeware only at the very beginning

  1. There is no error message when an out-of-bounds value is specified and "Save" is clicked. Can an

error dialog be generated here?
DONE: Added ToolTip with boundaries, added validation and red text color if input is wrong.
in last commit.
TODO: 3) - 6) + find way to disable plugin at the very beginning, "enabled option doesn't work most likely because of component loading order.

@ScottWell1 With our new two piece bed system, we are expecting customers to experiment with different beds, coverings, glass, etc. This may require a larger than standard offset, so we are not sure on hard limiting the change.

Looking at our build history, it looks that we have a calibration range on Z offset as following for the builds:

Glad -1.18 to -1.53
Foxglove -1.00 to -1.53

TAZ -1.05 to -1.58

@efilenko Can we add in a yellow warning for a separate range?

White highlighting: -1.2 to -1.4
Yellow highligting: -1.0 to -1.199, and -1.4 to -1.55
Red Highlighting: Anything else

@karrad -

I wondered about new beds, but assumed as long as the same thickness washer is used and is on top of the surface -- then offset should be the same.

My main concern with this feature (especially with single range for all printers) is with customers setting this too low, damaging their beds, then blaming it on Lulzbot/CuraLE -- leading to angry support calls. But if you guys aren't having a problem with that on Taz6 (where it can be changed on LCD), then maybe I'm just too cautious. :-)

I am in slight disagreement with your "White" vs "Yellow" highlighting. The firmware default on Taz6 is -1.20, meaning even +0.05 change to -1.15 would violate your "yellow" range of -1.0 to -1.199. Since going closer to zero won't damage anything (other than print not sticking), I would suggest expanding the "White" range: -1.05 to -1.4 (and shrinking the "Yellow" range accordingly).

@ScottWell1 We appreciate the feedback! In the recent rev, we dropped the Z offset to -1.2 by default. In legacy cura, we had mistakenly left it at -1.5 in Firmware, which trashed some beds after a FW update.

Looking at the numbers again, -1.1 to -1.4 Will be within the calibrated range of 95% of the printers we have created. Good call on the safety bounds, being too high will not damage anything.

@efilenko Can we add in a yellow warning for a separate range?

White highlighting: -1.05 to -1.4
Yellow highlighting: -0.80 to -1.049, and -1.401 to -1.55
Red Highlighting: Anything else

@alexei @karrad @ScottWell1 : In previous 2 commits I addressed only disable/enable issue for ZOffset plugin. At the very first start of Cura Preferences/Plugins/ZOffset is un-checked and doesn't shows up. When you check it and restart Cura you will see it, but you can not change ZOffset on the flash till you go and permit it under Preferences/General.

I didn't address this yet: @efilenko Can we add in a yellow warning for a separate range?

White highlighting: -1.05 to -1.4
Yellow highlighting: -0.80 to -1.049, and -1.401 to -1.55
Red Highlighting: Anything else
and didn't implement code for Octoprint, only for USB device.

As I understand it, this plugin was temporarily disabled (removed) from the .63 build for public release. But it still appears disabled in the .64 and .65 builds (at very least, __init__.py is missing from those builds). Can it be added back into Dev builds now so further testing can be done?

@allexei @karrad In last commit I addressed changing boundaries and coloring background as yellow, red and white (per @karrad description). Also added ZOffset to OctoPrint. TODO: Implement ability to save ZOFFset locally without saving it to EEPROM.

@karrad @alexei : Please, test. I addressed all issues. Z-Offset is a plugin (enable from Preferences/ Plugins page. Save to flash check box enable from Preferences/General page.

karrad moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 12 2018, 10:06 AM
karrad triaged this task as Low priority.
karrad reassigned this task from efilenko to alexei.Feb 5 2018, 12:50 PM
karrad renamed this task from Z Offset Value to Feature Request: Z Offset Value.Feb 19 2018, 11:28 AM
karrad removed alexei as the assignee of this task.Apr 4 2018, 10:05 AM
karrad moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

This will not get implemented in the next release, moving to backlog

alexei claimed this task.Apr 30 2018, 3:40 PM

@alexei Have you tried the existing plugin within Cura LE? https://forum.lulzbot.com/viewtopic.php?f=8&t=6946

I think this one accomplishes our goal, and we can likely close this out and just use the plugin.

With initial layer flow rate %, and the Z offset plugin currently available from fieldOfView we do not need to modify anything in marlin. per @alexei it is best if we remove existing commits from this ticket.

@karrad - Are you sure the plugin addresses this? I read the Lulzbot thread you linked, and the Stackexchange thread linked from there... And comments there say the plugin only applies to a raft. Have you guys tested the plugin with current CuraLE to verify it works and works with/without a Raft?

@ScottWell2 Ahh, we have not tested it with a raft thanks for the heads up. We will look into fixing that if it is an issue.