Support Minimum X/Y Distance Not Respected

[AbeFM]

I'm not sure if you want to take a look at this with your fork, I know you've seen me complain about this before. If it's not in the cards, that's fine.

https://community.ultimaker.com/topic/25759-please-slice-and-post/

In quick summary: Basically, I feel the support is using the greater of ("minimum x/y distance", "x/y distance") at all times. Instead, it should use X/Y except in Support Floors and Support Ceilings.

I can write it up better if you'd like, but won't waste your time if you don't care. :-)

[smartavionics]

Isn't this behaviour controlled by the Support Distance Priority setting?

Looking at the code, when Support Distance Priority is set to "X/Y overrides Z" it should use Support X/Y Distance rather than the minimum.

[AbeFM]

Ah, ok, thought you may have been familiar with the issue.

Desired Behavior: For support floors and ceilings, use the "Minimum X/Y Distance", and use the "X/Y Distance" when "Z Overrides X/Y" is selected.

The effect of not using that is the first layers of support (even tens of layers) are NOT PRINTED ON THE MODEL. They are printed in mid air, don't stick, get drug around, stick to other things, leave holes and worst of all you get support failures because the bottom several layers are missing.

I can put up more pictures, etc. Sometimes it works right, there's a guy with a Mac who seems to get the right results. And I do sometimes. But I can't think of a good reason to intentionally add a gap when the user sets a number.

If I'm using it wrong, I would love to know. Otherwise, I need to know how to get supports to stick to sloped surfaces.

Looking closely, only ~1 mm over the second to top layer touches the model (I think an accident) and the very top layer on the model touches for about 10% of its area. But the rest of the entire support is way off the surface.

[smartavionics]

Desired Behavior: For support floors and ceilings, use the "Minimum X/Y Distance", and use the "X/Y Distance" when "Z Overrides X/Y" is selected.

And what behaviour do you want for non-floors and ceilings? You have to spell it out for me as I can't guess your requirements.

[AbeFM]

It's not really floors and ceilings.

My thought is the check looks something like this:

X/Y_distance = Std_X/Y_Distance
If (Z-OveridesXY == TRUE)
 {
   If ( (ObjectZ - CurrentLayerZ) < ZContactDist )
                 X/Y_distance = min_X/Y_Distance
  }

and I think I'd like something like:

X/Y_distance = Std_X/Y_Distance
If (Z-OveridesXY == TRUE)
 {
   If (  (ObjectZ - CurrentLayerZ) < ZContactDist ) || (Object_UnderZ - CurrentLayerZ) > ZContactDist
                 X/Y_distance = min_X/Y_Distance
  }

I'm no programmer, I hope that makes sense. You're right, it has nothing to do with cielings and floors, I just thought that would make it easier to implement.

What I want is Z overrides X/Y for both above and below. This seems obvious to me, but if you're not getting it perhaps I'm misunderstanding how to obtain the results I'd like (my supports to print on my object, instead of in free space). I assume you see the gaps in the picture, but I can get better images if I'm unclear.

[smartavionics]

I don't really understand the problem. Here's your example object from the forum, the support can be made as close as one wants to the sloping surface....

[AbeFM]

There are TWO variables: "Support X/Y Distance" AND "Support X/Y Minimum Distance"

I do not see the utility in them if you MUST set them the exact same in order for the second one to do anything. The tooltip from "Support Distance Priority" seems to explain what I (and whoever wrote the code) had in mind: The ability to have a larger X/Y distance (to keep perimeters clean) while still achieving close supports for overhangs and islands.

Does what I want to accomplish (Islands that print and supports that stick while maintaining reasonable X/Y separation - by putting my PVA touching the object instead of several layers away) sound reasonable?

If I'm missing something, I've been missing it for well over a year, and I would appreciate figuring a way to make the Support Z Distance be the number I type into the box.

[AbeFM]

I guess your lack of response means you still don't understand?

I REALLY want to get my point across. Please help me to do so. If I am not clear, ask questions, and if I am clear, answer my questions. I'm sure we can both understand each other with some effort.

My goal: To have my supports stick to my model without ruining side walls. My approach: Print supports so their first layers touch the model. My issue: CURA specifically avoids the model when printing support, ignoring Minimum XY Distance setting..

I would like to use the "Support XY Distance" to prevent my supports from merging with the object (embedding PVA into the print which leaves holes and rough surface on near-vertical and vertical walls), and use "Minimum Support XY Distance" to allow the support to make reliable contact with the top/bottom surfaces of the model.

[smartavionics]

I guess your lack of response means you still don't understand?

Sorry, I'm just busy and Cura stuff isn't the highest priority for me.

I did look at the support code but didn't get very far. I will look some more when I can but can't say when any changes will be. I'm not familiar with the support code so it will take me a while to become acquainted with the original programmer's intentions. Believe me, in Cura, it's not always very obvious what they were intending!

[AbeFM]

That's totally great! I just want to know if I'm making my point or not.

If I'm explaining myself I'm already a step ahead of the last year of work. :-)

[smartavionics]

i think I have the idea now. How does this look to you:

I will make a build before the day is done that has this so you can test it.

[smartavionics]

I printed it (PLA) without the bottom interface and using a min x/y of 0.3 and it came out just fine. Supports stuck to the side OK but then were easy to remove.

I got even better results using a wall around the support and 10% gyroid support. Quick to print and very easy to remove.

[AbeFM]

I think we're onto something! The real question is something curved, but a shape like the one I did in my earlier post would tell us how it's dodging vertical walls. What you've got looks right and certainly it would stick.

I'm a little surprised at the interaction at the overhang - the dark blue layers are pulled away from the tower whereas I would expect them to be closer (using MinXY distance?). You have the case from my 3rd image (top half of it, anyways), but I am looking for the 4th (using MinXY, not 0)

It sort of looks like you have 'support interface horizontal offset' set.

You're WELL on the right path here. This will improve the lives of many people, at least one I care about very much. :-)

If it'll run on win10, I can test it.

[smartavionics]

I think we're onto something! The real question is something curved, but a shape like the one I did in my earlier post would tell us how it's dodging vertical walls. What you've got looks right and certainly it would stick.

I tried it on a curved object and it looked OK.

I'm a little surprised at the interaction at the overhang - the dark blue layers are pulled away from the tower whereas I would expect them to be closer (using MinXY distance?). You have the case from my 3rd image (top half of it, anyways), but I am looking for the 4th (using MinXY, not 0)

But at that region of the model there is no overhang. The min xy only gets applied to layers that overhang the layer below. So I think the result is to be expected given how the code works.

BTW, I am on holiday from tomorrow for a week so no updates for a while.

[AbeFM]

FYI: I'm asking all this in the hopes of using PVA - so contact distanced on Z should all be 0.

I think we're onto something! The real question is something curved, but a shape like the one I did in my earlier post would tell us how it's dodging vertical walls. What you've got looks right and certainly it would stick.

I tried it on a curved object and it looked OK.

I'm a little surprised at the interaction at the overhang - the dark blue layers are pulled away from the tower whereas I would expect them to be closer (using MinXY distance?).

But at that region of the model there is no overhang. The min xy only gets applied to layers that overhang the layer below. So I think the result is to be expected given how the code works.

I would expect Min X/Y to be applied anytime you're within Support (Top) Distance. Perhaps Support (top) - 1 layer? The idea (I think) is that you'll get supports that might be too snug to leave a nice side, but you need it to get a small overhang supported. Are you saying since it's a bridge it's not a factor?

Something round to look at. SupportRemovalTest.3mf.txt

I will make a build before the day is done that has this so you can test it. You mean download from github and compile? If you get a chance before you leave, put something up and I'll try it while you're gone.

BTW, I am on holiday from tomorrow for a week so no updates for a while. Enjoy your holiday!!

[AbeFM]

Hey howdy! Looks like things are pretty busy on the main CURA site.... But I'm basically at the point where I can get supports that stick to the model AND glue to vertical walls (setting XY to 0.1) or supports that fail every time (X/Y to a line width or so).

Do you have something I can try? I'd be willing to compile it if need be.

[smartavionics]

Did you try the 0802 build?

[AbeFM]

No, sorry, I don't know what to do other than my requests in this thread for something to try.

You recommend downloading that version from this repository? Will do!

              Thanks!
                      -Abe.

Sent from my "smart"phone, please excuse brevity and Swype-oes

On Sun, Aug 11, 2019, 5:31 AM Mark Burton notifications@github.com wrote:

Did you try the 0802 build?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/smartavionics/Cura/issues/12?email_source=notifications&email_token=AAAKLEOR5UNKESQWYW3EHUDQEABBJA5CNFSM4IGT2VN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4A757Q#issuecomment-520224510, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAKLEOOPR6B2OO7RP3P2PDQEABBJANCNFSM4IGT2VNQ .

[smartavionics]

You recommend downloading that version from this repository? Will do!

There's pre-built releases for Linux and Windows available from https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

[AbeFM]

Thank you thank you thank you!!!!

Off to a rough start: That is a pretty oddball case, so I wouldn't worry about it too much.

Looking at something more representative, here's my standard test model....

4.1:

802:

Huh, is there a way to make it not support bridges? Irrelevant for my use, but I'd never noticed it before (my test model didn't used to have the roof). It happens in both versions.

Similarly, this is an issue on both:

I think both of these are consequences of the settings working correctly, so it's probably not anything to do anything about though if they happened in a hard to see place it would lead to failed prints without anyone knowing why.

I'll get to testing, but right off the bat I'd say you've fixed a 2 year old problem!!!

[AbeFM]

First couple prints performed admirably. I had a support failure on each machine, I believe due to weak initial extrusions after a solid prime tower. I was hoping to be able to ignore it, but it doesn't seem so.

Is there anything in particular I should test, or just kinda use it and say what I see?

[smartavionics]

Hi, thanks for the feedback. I don't have anything in particular in mind to test so please just use it some more and let me know if there are any problems. After a while if it's looking OK, I will submit a PR to Ultimaker.

[AbeFM]

A little weirdness, as of yet unsure if it is related:

I believe it is using the wrong material for the very extreme layer of supports - perhaps the interface is using a different distance?

I didn't see a change over support density, pattern...

Ah, it comes from having the minimum support interface area larger than the minimum support area.

[AbeFM]

Different from the issue in previous post: This is really working great! I'm getting my supports to hug my model, but not blemish. There's interface anywhere they are really close, and as you can see, it also doesn't force contact where it isn't needed.

I'm a little puzzled why it hasn't always worked this way - I feel it was a bug not a design choice. :-)

[smartavionics]

I believe it is using the wrong material for the very extreme layer of supports - perhaps the interface is using a different distance?

I didn't see a change over support density, pattern...

Ah, it comes from having the minimum support interface area larger than the minimum support area.

I haven't made any changes in this regard, the behaviour should be the same in Ultimaker's build.

[AbeFM]

This is just you posting the code I've been using to CURA proper? No further changes?

Unrelated: Is there a "don't support bridges" equivalent? I have some designs with lots of printable bridges that end up generating supports that I could block manually if I must.

[smartavionics]

This is just you posting the code I've been using to CURA proper? No further changes?

Correct.

Unrelated: Is there a "don't support bridges" equivalent? I have some designs with lots of printable bridges that end up generating supports that I could block manually if I must.

No, sorry.

[AbeFM]

I want to make my soluble interfaces larger so that the PLA can fit out of holes it is printed inside of. I'm not yet sure what's causing it, but it seems like the supports are largely missing.....

Will add more if I learn anything.

I've been playing with stair step height, expansion, pattern.... not seeing any improvement. Hex1Missing Supports.3mf.txt

If I should move discussion to main CURA GitHub, let me know.

[AbeFM]

A couple more shots to illustrate behavior, varying floor thickness.

3mm roof, 1 mm floor

3mm roof, 3 mm floor Significant holes.

3mm roof, 7 mm floor Missing entire floor?

There's a chance that non-floor support is being removed proportional-but-not-equal to the floor thickness?

I tried setting the XY distance lower, no change.

Lastly, set XY overrides Z, no change:

[AbeFM]

Final point unless I find the difference - same file, closely related settings, this slices ok. Not sure the difference.

Hex1WorksOK-printed.3mf.txt

Is there a easy way to compare profiles?

[AbeFM]

Nevermind. That previous file doesn't work either if I make the roof and floor large.

I sure is a lot of work to turn "don't print unsupported material" into code, huh?

As usual, anything I can do to illuminate the issue I'm willing to help with.

---

Ledges are 10, 15, 20 mm apart Inner humps are 0, 5, 10 apart. Slopes are 15 or 30 degrees All orientations match

8/8 Roof/Floor

1/13 Missing some on bottom as the issue on the forums currently, I think Missing on the right, not sure why

13/1 Missing a lot of bottoms. No idea why.

Perhaps this is not related to X/Y and should be on the main forums? Let me know, I can post there.

[smartavionics]

Can you please provide a project file for this last example. Thanks.

[smartavionics]

I found your project file at https://github.com/Ultimaker/Cura/issues/6183.

This is with 2/2, looks OK?

[smartavionics]

Maybe there's a problem in the upstream support code that causes weirdness when the required support height is < (roof thickness + floor thickness) ?

[AbeFM]

That's why I listed the dimensions of the part, there's a 10, 15, and 20 mm gap, so it's easy to test the behavior.

It feels very much like that - something about the total gap and the floor/roof thickness, but I've yet to tease out what makes it misbehave. Got drug out for breakfast but can play for a bit now. Will check in if I find anything definitive.

It seems ok in 4.2.1 (and your first X/Y distance release I was so happy with).

Speaking of, can I just install that old one now over my current "master" to get back to functional printing?

[smartavionics]

There have been upstream changes in the handling of support so it is possible that they have introduced new bugs. I haven't made any changes there recently.

Speaking of, can I just install that old one now over my current "master" to get back to functional printing?

Probably, I don't use Windows so I can't say for sure. One possible problem is that config files may have got changed in a later release so they are no longer compatible with an earlier release. One never knows as they are fucking around all the time with the config stuff.

I have all of my config files in a git repo which I occasionally commit a snapshot to. So if I wanted to do what you are suggesting (install an older release) I would make a snapshot of the current config files before running the older release so that if anything gets screwed you can recover. Of course, just making a copy of the config files directory first would be sensible.

[AbeFM]

...I'll try that. I guess running two versions called "master" at the same time is a poor choice? :-)

I think you're right, you need a "no pissing in the river on Tuesdays" sign, keep the upstream source pure. :-)

[smartavionics]

I can confirm that the part of cura that handles the roof and floor of the support has had upstream changes very recently...

9706b0ee7 (Lipu Fei          2017-07-05 14:48:17 +0200 1467) void AreaSupport::generateSupportRoof(SliceDataStorage& storage, const SliceMeshStorage& mesh, std::vector<Polygons>& global_support_areas_per_layer)
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1468) {
33b9fedf8 (Ghostkeeper       2018-08-17 14:57:16 +0200 1469)     const Settings& mesh_group_settings = Application::getInstance().current_slice->scene.current_mesh_group->settings;
33b9fedf8 (Ghostkeeper       2018-08-17 14:57:16 +0200 1470)     const coord_t layer_height = mesh_group_settings.get<coord_t>("layer_height");
58a357892 (Cherubim          2018-08-21 09:51:07 +0200 1471)     const size_t roof_layer_count = round_divide(mesh.settings.get<coord_t>("support_roof_height"), layer_height); //Number of layers in support roof.
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1472)     if (roof_layer_count <= 0)
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1473)     {
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1474)         return;
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1475)     }
58a357892 (Cherubim          2018-08-21 09:51:07 +0200 1476)     const coord_t z_distance_top = round_up_divide(mesh.settings.get<coord_t>("support_top_distance"), layer_height); //Number of layers between support roof and model.
58a357892 (Cherubim          2018-08-21 09:51:07 +0200 1477)     const size_t skip_layer_count = std::max(1u, round_divide(mesh.settings.get<coord_t>("support_interface_skip_height"), layer_height)); //Resolution of generating support roof below model.
dc6f2a4f4 (Ghostkeeper       2018-08-20 13:28:42 +0200 1478)     const coord_t roof_line_width = mesh_group_settings.get<ExtruderTrain&>("support_roof_extruder_nr").settings.get<coord_t>("support_roof_line_width");
bf3b98e90 (Vlad Gribinchuk   2018-10-09 10:48:58 +0300 1479)     const coord_t roof_outline_offset = mesh_group_settings.get<ExtruderTrain&>("support_roof_extruder_nr").settings.get<coord_t>("support_roof_offset");
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1480) 
c760cceb7 (Diego Prado Gesto 2018-09-04 15:16:09 +0200 1481)     const size_t scan_count = std::max(size_t(1), (roof_layer_count - 1) / skip_layer_count); //How many measurements to take to generate roof areas.
8c39203ce (Ghostkeeper       2017-03-16 16:21:21 +0100 1482)     const float z_skip = std::max(1.0f, float(roof_layer_count - 1) / float(scan_count)); //How many layers to skip between measurements. Using float for better spread, but this is later rounded.
8e1f9d125 (Vlad Gribinchuk   2018-09-28 13:05:03 +0300 1483)     const double minimum_roof_area = mesh.settings.get<double>("minimum_roof_area");
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1484) 
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1485)     std::vector<SupportLayer>& support_layers = storage.support.supportLayers;
58a357892 (Cherubim          2018-08-21 09:51:07 +0200 1486)     for (LayerIndex layer_idx = 0; layer_idx < static_cast<int>(support_layers.size() - z_distance_top); layer_idx++)
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1487)     {
58a357892 (Cherubim          2018-08-21 09:51:07 +0200 1488)         const LayerIndex top_layer_idx_above = std::min(static_cast<LayerIndex>(support_layers.size() - 1), layer_idx + roof_layer_count + z_distance_top); //Maximum layer of the model that generates support roof.
15e133908 (Ghostkeeper       2017-04-24 14:48:07 +0200 1489)         Polygons mesh_outlines;
db1a7f52c (Ghostkeeper       2017-03-16 16:18:20 +0100 1490)         for (float layer_idx_above = top_layer_idx_above; layer_idx_above > layer_idx + z_distance_top; layer_idx_above -= z_skip)
671ebccdb (Tim Kuipers       2017-01-20 14:08:56 +0100 1491)         {
15e133908 (Ghostkeeper       2017-04-24 14:48:07 +0200 1492)             mesh_outlines.add(mesh.layers[std::round(layer_idx_above)].getOutlines());
671ebccdb (Tim Kuipers       2017-01-20 14:08:56 +0100 1493)         }
b2317fb98 (Ghostkeeper       2017-03-20 13:51:15 +0100 1494)         Polygons roofs;
6bd2847fd (Vlad Gribinchuk   2018-11-09 21:10:55 +0200 1495)         generateSupportInterfaceLayer(global_support_areas_per_layer[layer_idx], mesh_outlines, roof_line_width, roof_outline_offset, minimum_roof_area, roofs);
5f8907a6b (Vlad Gribinchuk   2018-11-28 12:46:41 +0200 1496) 
ac14fbf26 (Vlad Gribinchuk   2019-02-04 12:14:33 +0200 1497)         if (layer_idx > 0)
5f8907a6b (Vlad Gribinchuk   2018-11-28 12:46:41 +0200 1498)         {
ebdf17f1e (Vlad Gribinchuk   2019-07-30 15:07:02 +0300 1499)             Polygons test_polygons;
ebdf17f1e (Vlad Gribinchuk   2019-07-30 15:07:02 +0300 1500)             const auto actual_support_offset = getActualSupportOffset();
ebdf17f1e (Vlad Gribinchuk   2019-07-30 15:07:02 +0300 1501)             test_polygons.add(support_layers[layer_idx - 1].support_roof);
ebdf17f1e (Vlad Gribinchuk   2019-07-30 15:07:02 +0300 1502)             test_polygons.add(global_support_areas_per_layer[layer_idx - 1].offset(actual_support_offset).offset(-actual_support_offset));
ebdf17f1e (Vlad Gribinchuk   2019-07-30 15:07:02 +0300 1503)             removeDanglingInterface(roofs, test_polygons);
5f8907a6b (Vlad Gribinchuk   2018-11-28 12:46:41 +0200 1504)         }
b2317fb98 (Ghostkeeper       2017-03-20 13:51:15 +0100 1505)         support_layers[layer_idx].support_roof.add(roofs);
c0715fd49 (Tim Kuipers       2015-06-11 13:57:23 +0200 1506)     }
c0715fd49 (Tim Kuipers       2015-06-11 13:57:23 +0200 1507) }

If you want to see the upstream PR, it is https://github.com/Ultimaker/CuraEngine/pull/923.

[AbeFM]

Model Slopes of 15 and 30 degrees (75 and 60 from vertical)

Interfaces Ex1, Infill Ex0, 65*

Interfaces Ex1, Infill Ex1, 65*

Interfaces Ex1, Infill Ex0, 55*

Interfaces Ex1, Infill Ex1, 55*

Interfaces Ex1, Infill Ex0, 30*

Interfaces Ex1, Infill Ex1, 30*

Ok, how about this for a theory: The roof or floor is being interpreted as the mirror of the angle (90-angle) instead of the angle, so they are doing different things?

[smartavionics]

I haven't a clue. It's not my area of interest. You need to open an upstream issue and talk to the people who are making the changes.

[AbeFM]

I seem incapable of posting over there without stepping on toes, but I would like to help. Do you think there's a particular existing issue to put this all in?

[smartavionics]

Why not comment on the upstream PR I mentioned above. Explain the problem you are seeing and how it wasn't occurring before that PR was merged.

[AbeFM]

Okey!

[AbeFM]

Speaking of, can I just install that old one now over my current "master" to get back to functional printing?

Probably, I don't use Windows so I can't say for sure. One possible problem is that config files may have got changed in a later release so they are no longer compatible with an earlier release.

I loaded the older release (0802) over the top, after backing up, slicing would get ~ halfway and hang. Putting the latest over again did restore it to functional.

Probably setting up to compile 0802 and giving it a version number so it won't conflict with "master" will open several worm-cans. Do you have any suggestions on how to go back to that best-CURA-from-the-past-couple-years version? :-)

The support updates you made completely fixed the old issues and I'd like to be able to use it without causing you undue effort.

[AbeFM]

I tried reinstalling the 08/02 release after deleting the CURA MASTER directoy, and when CURA comes up I had to tick all the boxes and add a printer.

The included printer works fine. If I load a project (model only) it still works fine.

When I load a project (saved on 8/17, when I was still using 08/02), it goes back to only slicing halfway then hanging there indefinitely. Switching to an included printer makes it work again.

Adding an Ultimaker 3 and using built in profile, it also hangs. Even disabling the second extruder (GUI tick box, not in printer def) won't fix it.

It looks like somehow I can't do dual extruder printers on 08/02. Any advice on getting back to it (or compiling the current code without the new support issues) would be super useful. I had a week of great productivity and I would love to go back to it.

[smartavionics]

Sorry to hear you are having problems still. As for the new support issue, can't you just use little or no interface depth to workaround the missing support? I don't want to revert the upstream changes unless it proves to be absolutely necessary because it will make life difficult in the future. Did you comment on their commit and get any response from them?

[AbeFM]

I have, it's getting to be quite a thread! I certainly don't want to make it difficult.

I cannot use thin interfaces because I cannot get my supports out.

The soluble supports from table to part cost ~2x the rest of the print. My simplistic request to generate support with and without "buildplate only" supports and print the later in soluble apparently won't work. Anything under ~5-10 mm of interface won't even come close to letting supports out, and using that causes problems.

I was going to subtract my model from a block and have that print as a solid object or something, but now I cannot slice AT ALL so I'm dead in the water.

[AbeFM]

To finish that thought: I use thick floors because they won't add to wasted PVA under the part. Thick roofs help the support release, too, so I try to find a good compromise.

Isn't there a "drop down mesh support" or something which defines the area under the model? Being able to use that volume to define a different Support Infill Extruder would solve all my problems, I think. :-)

[smartavionics]

OK, I have located what I think is the bad new code. I'm not going to try and fix it (they can do that) but I can simply disable it. When I do that, I get these results. Do they look OK?

I am making a build for you right now, will be available later...

[AbeFM]

Yeah, that looks great, and disabling was just what I had in mind. Ideally I can test their issue with my 4.2.1 install and use "master" for printing. :-) Guess I can close that "2 week trial" for S3D page again.

[smartavionics]

The 0826 build is now on dropbox. Good luck!