The relationship between the Z-axis accuracy problem caused by variable layer height and the minimum Z-axis layer height

[gaifeng8864]

Is there an existing issue for this feature request?

• [X] I have searched the existing issues

Is your feature request related to a problem?

As we all know, the Z-axis height in normal slicing mode is (number of slice layers * layer height). But this value often has errors with the design value of the model itself. For example, when the model design height is 2.1mm and the slice layer height is 0.2mm, the slicer will actually generate 10 or 11 layers of slices, resulting in a slice error of +-0.1mm. Although this error is small, it is a serious problem in some special cases. For example, if there is a +-0.1mm error in the height of the idler seat and the slider at both ends of the X axis of a coreXY structure 3D printer, it is very obvious and seriously affects the accuracy of the printer. I know that variable layer height can be used to improve this problem. But I found that when we set the minimum and maximum values ​​of the layer height, the automatic variable layer height cannot be automatically adjusted according to the integer multiples of the minimum value. For example, let's take the dimensional error mentioned above. Normally, when we set the minimum layer height to 0.1mm, the variable layer height should be able to correctly identify the design height as 2.1mm, and then slice it into 11 layers, one of which is 0.1mm, and the other 10 layers are all 0.2mm, which is a perfect result. Or there can be 3 layers with a height of 0.1mm and the other 9 layers with a height of 0.2mm, which is also a very good result. However, after many tests, the actual situation is not like this. The slicer is a bit superfluous. It will automatically generate many layer heights with multiple decimal places between 0.1mm-0.2mm, such as 0.100230mm, and so on. The superposition of these values ​​results in the final slicing result still not being an exact 2.1mm, but 2.03mm. Or 2.13mm, and so on.

Which printers will be beneficial to this feature?

All

Describe the solution you'd like

This makes me very confused. Shouldn't the primary task of the slicer be to ensure the dimensional accuracy of the slices as much as possible? The accuracy of the automatically generated layer height value has reached 4-5 decimal places, which is far higher than the Z-axis motion accuracy of most printers. Is it really necessary? Why can't the slicing software recognize the automatic layer height change division value as the minimum layer height? In this way, you can freely configure the minimum layer height according to the Z-axis motion capability of the printer to avoid unnecessary calculations and errors. At the same time, you can appropriately select the minimum layer height according to the design height of the part to achieve the number of slices to be an integer multiple of the minimum layer height, thereby meeting the accuracy requirements.

Describe alternatives you've considered

Lower the height of the first layer to cooperate with the slicer to generate the correct layer value. For example, if the height of the first layer is set to 0.1mm and the height of other layers is 0.2mm, then according to the design value of 2.1mm in the above description as an example, it will generate 11 slices with a total height of 0.1mm+0.2mm*10 layers. This will generate the correct total height of the Z axis. However, this is only the total height. If there are other planes of different heights in the middle of the print, the accuracy still cannot be accurately controlled.

Additional context

No response

[igiannakas]

There is a proposed pull request that rounds this to three digits. https://github.com/SoftFever/OrcaSlicer/pull/5795

There is a conversation in that PR whether that makes sense or whether rounding to a larger number (0.01) may be beneficial. But in any case you can test the changes there ;)

[igiannakas]

Also there is a new feature now in 2.1.1 where you can enforce a precise Z height (it's called exactly that and it's in the quality tab -> precision). However dont enable it without reason, as adjusting the layer height to make a precise Z height for multi color prints can result in incorrect colouring of some layers. Only use this when striving for dimensionally accurate parts below half your layer height.

[gaifeng8864]

In fact, in principle, only the Z axis in FDM-based 3D printers has strictly controlled dimensional accuracy, while the XY axis is not strictly controllable in terms of accuracy because it involves the extrusion and expansion of consumables. In addition, in actual use, the Z axis direction is often used as a high-precision assembly reference surface. Therefore, please seriously consider the above suggestions and improve the slicing accuracy of the Z axis as much as possible, not only the total height of the Z axis, but also the height of all planes on the Z axis should be guaranteed to be accurate, at least do not introduce unnecessary errors in the slicing software.

[igiannakas]

Actually the Z height is not fully controllable either. There is material expansion upwards, especially due to setting the extrusion flow rate multiplier. Also you have thermal contraction and expansion that again is not fully controllable - it depends not just on the absolute shrinkage rate of the material but also on how long the fan spends over a specific spot of a specific layer etc.

Trying to achieve absolute precision with a robotic hot glue gun is impossible, so the best way is to design for tolerances.

the two changes above go a long way to improve this, suggest you give them a spin and report back..

[gaifeng8864]

Also there is a new feature now in 2.1.1 where you can enforce a precise Z height (it's called exactly that and it's in the quality tab -> precision). However dont enable it without reason, as adjusting the layer height to make a precise Z height for multi color prints can result in incorrect colouring of some layers. Only use this when striving for dimensionally accurate parts below half your layer height.

Thanks for your reply. I also noticed and tested this new feature. It can indeed generate accurate total Z-axis height, but it does not work for planes other than the top surface on the Z axis. Every plane with different heights on the Z axis should have sufficient accuracy.

[gaifeng8864]

There is a proposed pull request that rounds this to three digits. #5795

There is a conversation in that PR whether that makes sense or whether rounding to a larger number (0.01) may be beneficial. But in any case you can test the changes there ;)

There is a proposed pull request that rounds this to three digits. #5795

There is a conversation in that PR whether that makes sense or whether rounding to a larger number (0.01) may be beneficial. But in any case you can test the changes there ;)

I also checked this PR, but how can I change the number of decimal points for variable layer height? I didn't find a separate setting option for this. In addition, what do you think about setting the variable layer height's change division value as a separate option or linking it to the minimum layer height value?

[igiannakas]

I wouldn’t make it more complicated than it needs to be. The firmware either klipper or others have internal quantisation of z height changes too.

personally I think that 0.01 is a good place to be precision wise but that needs testing with several nozzle sizes and layer height prints.

You can change that directly in the code for now but not in the UI

https://github.com/SoftFever/OrcaSlicer/pull/5795/files

height = std::round(height * 1000) / 1000.f;

The 1000 value means 3 decimals. Changing both to 100 results in 1 decimal etc.

[gaifeng8864]

I wouldn’t make it more complicated than it needs to be. The firmware either klipper or others have internal quantisation of z height changes too.

personally I think that 0.01 is a good place to be precision wise but that needs testing with several nozzle sizes and layer height prints.

You can change that directly in the code for now but not in the UI

https://github.com/SoftFever/OrcaSlicer/pull/5795/files

height = std::round(height * 1000) / 1000.f;

The 1000 value means 3 decimals. Changing both to 100 results in 1 decimal etc.

Is there anything special I need to pay attention to when compiling after the changes?

[igiannakas]

Nope nothing special - just follow the instructions for your platform

[gaifeng8864]

Nope nothing special - just follow the instructions for your platform

Thank you very much for your enthusiastic response.

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.