Positive values flagged as illegal on interface support layer horizontal expansion

[Liger0]

Application version 4.8 beta

Platform Win10 x64

Printer Cr10s

Reproduction steps

1. Put a positive value on interface support layer horizontal expansion
2. (Something you did next.)

Screenshot(s) (Image showing the problem, perhaps before/after images.)

Actual results The box is flagged red for an illegal value

Expected results Positive values should make sense

Project file (For slicing bugs, provide a project which clearly shows the bug, by going to File->Save. For big files you may need to use WeTransfer or similar file sharing sites.)

Log file (See https://github.com/Ultimaker/Cura#logging-issues to find the log file to upload, or copy a relevant snippet from it.)

Additional information (Extra information relevant to the issue.)

[nallath]

I've tried reproducing this, but it lets me fill in "4" without getting any warning / error what so ever.

Could you share a project file?

[Liger0]

support interface expansion.zip

[nallath]

Ah yeah. I see the issue now. The max value of the setting "Support Interface horizontal expansion" is set to give an error if it' s more than the value of "Support Horizontal Expansion"

I'm not quite sure why this was added, but i assume it's to ensure that the interface is always supported. Why do you want to change the horizontal expansion of the interface, but not of the support itself?

[Liger0]

I was trying to use support interface expansion on tree supports for testing purpose at first, since it is broken. #8622

[Ghostkeeper]

I'm not quite sure why this was added, but i assume it's to ensure that the interface is always supported.

This was a technical limitation, actually. We split off the support interface from the main support areas. Allowing the support interface to go beyond the main support area is a nightmare of getting it to adhere to the X/Y distance, the bottom distance and stair stepping again. (Developers, see CURA-5880 for the source of this assessment.) We said then that we wouldn't do this because it would effectively almost double the amount of clipper operations necessary. Although it would be operating on a lower amount of data, it would still take a lot of extra computation time. And it would add greatly to the complexity and number of bugs in the code.

So I think we'll have to reject this feature, due to technical limitations.

[printingotb]

Shouldn't "support interface horizontal expansion" automatically calculate to the value of "support horizontal expansion" though? (unless you change it). Support interface expansion.zip

Ps. Why I have wanted to use a larger interface expansion is to be able to easier get a tool in between the model and the support, while still supporting the overhang all the way to the edges as well. Not sure how it would work out since I couldn't test it. :upside_down_face: Now that I think about it, what I actually wanted was different X/Y difference for support and interface. Anyway, I understand that you won't do it.

[Ghostkeeper]

Shouldn't "support interface horizontal expansion" automatically calculate to the value of "support horizontal expansion" though?

The default is 0. That also doesn't cause problems as long as Support Horizontal Expansion is kept positive. Only your jonas pla 3 custom profile overwrites that to 1.

[printingotb]

I changed to the default normal profile now to make sure my custom settings don't mess anything up.

One of the main reasons that I have been using support horizontal expansion is to make it easy to get hold of the interface and remove the entire support structure as one piece.

If I only increase support horizontal expansion, the interface will not extend, only the normal support will and it may not be dense enough pull the interface off with it. So, naturally I increase both to be able to to do what I want. Later, if I want to change the support horizontal expansion, I may have hidden the interface expansion settings and forgotten about them. Even if not hidden, the interface expansion settings are placed much further down the list of support settings so you may not see them at the same time since those are outside the screen. As a user, this can be confusing when you get an error message when slicing.

That's when it would be useful if the interface expansion default value was a calculated value that matches the normal support expansion until the user changes it.

While I was testing this, I noticed that when the support expansion is increased, the interface horizontal expansion increases by exactly one line width (in the preview, not the actual value), regardless of the support expansion value. Even with interface expansion set to 0. I don't think that's a problem though.

[Ghostkeeper]

We've not found Support Interface Horizontal Expansion to improve quality significantly, so by default it's set to 0 to reduce printing time. Individual printers and profiles can still change it though, and can also change it to be equal to Support Horizontal Expansion and make it scale along.

While I was testing this, I noticed that when the support expansion is increased, the interface horizontal expansion increases by exactly one line width (in the preview, not the actual value), regardless of the support expansion value. Even with interface expansion set to 0. I don't think that's a problem though.

Indeed, I can reproduce this as well. Keen eye! I'll bring this up with the other developers to see what they think we should do about this.

[Vandrasc]

Devs see CURA-7836 for our own internal reference.

[GregValiant]

Is this still an issue in current versions of Cura (5.8.0 and up)? Can this be closed?