I was messing around with using PLA on a PETG print as the support interface since there is a large area to be supported and just using PETG as the full support makes that interface very difficult to remove. However, when I’m slicing the model, it’s putting an interface layer (blue) down low. Even more odd, there’s a layer of PETG right on the surface of the model and then two layers of the PLA (blue). The first image is a more extreme example. I did try printing the second image but it still has that odd layer of PETG on the surface below two layers of PLA. In the end, the subsequent layers of PETG on top of that PLA in the middle failed on several branches which caused a mess. Third image is just an exaggeration showing how it places a “shelf” on the model before the interface layer.
So, here are my questions:
How can I avoid those interface layers in the middle?
Why is it putting that “shelf” of PETG on the model before the interface layer (which essentially is worthless)?
Should I just go with normal supports here and just have the PLA as the interface on bottom and top? I was hoping to keep the amount of support minimized so using tree supports worked pretty well except for the interface layer.
Edit: Added a 4th image showing the first support layer using Tree Hybrid. Shown in orange here for PETG and then the next two layers are PLA. Is this a bug or is this how it should work? I’d think the interface layers should be printed first on the surface.
Another Edit: If I just do normal(auto) it doesn’t appear to add that layer in the 4th image and just starts laying down the interface layer directly on the surface. So a bug with how the tree supports are done?
You hadn’t mentioned what slicer and version you are using which might help us help you diagnose the problem. To say the least, support structures can often yield random results. My theory is that this may be due to floating point precision errors when the calculation is made but I have no way to prove that theory. However, to take a stab at some possible diagnostic methods, I might suggest this.
I routinely bounce back and forth between Orca Slicer(preferred) and Bambu Slicer(backup). In my experience I have found the following to be true:
I have experienced the slicer generating random errors without obvious cause. Sometimes simply repositioning on the plate and/or rotating the object just a few degrees will result in a completely different set of supports being generated. Have you tried that?
I also have found that closing the document and reopening can also create a new result after re-slicing. Have you tried that?
And last but not least. Closing the document in one slicer and reopening it in another will again yield a different result.
These are simply troubleshooting suggestions but worth a try.
Also, Orca slicer has a portable version that you might try using back-revision versions. By portable that means it is a zip file that runs in an isolated directory or even from a thumb drive. This would allow you to run different versions of Orca by placing them in their own folder. I have found that often times, I will get a different slice result with respect to supports by using a back-revved version.
I suspect that for the interface layer that a different filament is used, the rest of the support structure end up using the same filament. That’s causing the support structure to break during printing.
Well, it appears to be two bugs. One is the interface filament being used in the support structure and it looks like JonRaymond has reported that. The second is how tree supports are using regular filament as a first layer below the interface filament shoe in the 4th image.
Ah, it looks like having a layer height of 0.2mm and also an interface distance of 0.2mm causes the slicer to put down a model filament line to fill the gap?
That’s an interesting point. One thing I did fail to mention was this was sliced at .28 in my original images. I’ll have to check the settings that Kannekaffe shows as well.
