Vote for support (interface layer) improvements in Bambulab Studio

[T_guttata]

Dear all

Recently I had to print some complicated parts which involve support. I ran into a few issues which need to be solved.

I was in contact with Bambulab and they confirmed they are working on it, but it is unclear regarding priority / time frame.

To understand how big the pain is for the community, I would like your feedback.

Did you also encounter the issues I describe in the following section? Do maybe have something to add?

I use support only with an interface layer from a different material. The interface layer is roughly 1mm thick. It should work with printing PLA and using PETG as interface layer or vice versa.

For me personally the AMS is a game changer because it allows to use different material for the interface layer. As a result you can get perfect surface finish even for complex parts, which was impossible before. However, at the moment the reported issues will make it impossible to use the full potential!

I hope for support of the community to get the software improvements as soon as possible!

Issue 1) XY distance

All distances should be set to 0 for interface layer but not for the rest of the support. This is currently not possible since XY distance can not be set independantly.

More information can be found here: X/Y Support Distance Priority · Issue #2529 · bambulab/BambuStudio · GitHub

Issue 2) Missing bridging

Because of high material change times you try to minimize the amount material changes. Therefore, you only use support where it is needed. However, if done so, Bambulab Studio does not do any bridging layers for sections where no support shall be used. Since it does not make any sense and I can not change it, I call it a bug.
I have explained the phenomenon here (Bambulab Studio sections seems a bit sparsely populated): Support blocker results in missing Bridging layer in Bambulab Studio

Issue 3) Needless bridging

I have realized that Bambulab Studio in some cases does insert a bridging layer even though support is used with z-distance 0 and an interface layer. Because of the reduced material flow the layers even bond together with different material (PLA/PETG). The result is you can not or only hardly remove the support.
Unfortunately I have no picture to show this issue. I dont’ see any reason why bridging should be done when using support with an interface layer. It’s maybe not a “real bug” since the layer makes sense when using the same material for support. In conjunction with a different material however, it really is not working.

Edit:

Issue 4) Support Interface Speed

(thanks @ Verkinix)
Support Interface Speed affects layer BELOW instead of ABOVE the material interface change.
The support interface speed appears to apply only to the layer BELOW the support interface rather than ABOVE the material interface. As it pertains to PETG/PLA, the material change will “slide” or “string” if it’s going to fast on TOP of the interface change. Adding a control to control the speed of the material change layer ABOVE the interface would be a nice addition for situations like this.

Issue 5) Flushing volume for filament change

If the flushing volume is not high enough you basically make a predetermined breaking point by design in the layer of material change. I did some testing with a testpart and I had to increase the flushing volume to at least 500 mm3 to not severly alter the mechanical properties. In some cases even more might be required.
The current matrix with flushing volumes are meant for color changes, but not material changes. I would therefore propose the following:

• Give the possibility to have a flushing volume which is greater than 999 mm3 (current max).
• Give a possibility to define flushing volume for changes of material type. For instance: if you go from PETG to PLA, it will not depend that much on the color. So, it would be more conveniant to globally set a min flushing volume for changes in material type.

[Verkinix]

I’m sorta in the same boat, though I have an issue to add & suggestion for improvement.

Issue 4) Support Interface Speed affects layer BELOW instead of ABOVE the material interface change.

[tldr] It would be great to have an additional speed control added for Support Interface Speed (ABOVE) which would apply speed to the material printed ABOVE the opposite material interface (Currently Support Interface Speed applies to the layer BELOW the material interface). With low adhesion materials like in the PLA/PETG interface, the layer ABOVE will need to be slowed down.

The support interface speed appears to apply only to the layer BELOW the support interface rather than ABOVE the material interface. As it pertains to PETG/PLA, the material change will “slide” or “string” if it’s going to fast on TOP of the interface change. Adding a control to control the speed of the material change layer ABOVE the interface would be a nice addition for situations like this.

I did a test print tonight where I had a PLA support “raft” followed by a letter “t” in PETG (white) and finally a square tile PETG (black) (basically a scrabble tile with an extruded letter facing down; I know this is easily printed upright and needs no support, but this was a proof of concept for a more complex design where downward facing on support printing is needed). The raft printed fine at normal layer 1&2 PLA on the cool plate. The "t"s first layer interface to the PLA was at full speed (I couldn’t slow that down without slowing down the entirety of the print). It did print alright, but a larger design of similar nature I’d previously tried had alot of issues where everything stringed out at that interface.

Now I was oddly able to test the slow interface ABOVE the support layer in this print. Setting bridge to low speed and first layer infill to low speed had the desired affect on the “square tile” PETG (black) at the TOP of the raft with the entire layer ABOVE the interface at the low speed. That worked flawlessly and proved the concept. Every layer above that was run at normal speeds and printed really well and really fast. The same settings didn’t affect the “t” first layer at all unfortunately. There was a layer (I think it was the 3rd or 4th) of the “t” that printed at the slow speeds uniformly. That would have been ideal as the first layer ABOVE the material interface rather than several layers up where it’s printing on the same PETG.

This was all done with the X1C/AMS. Just a fabulous machine!

Edit: Added Picture
The print turned out decently. There was a little fray on the bottom layer white from the PETG printing too fast. Being able to control the speed of that layer explicitly would likely resolve the issue. Notice the facing layer of the black PETG is flawless. That layer did print entirely at the slow speed above the interface. Definitely a useful technique in certain applications to have the support interface sides controlled. What’s cool about how this tile turned out is that the top and bottom have a consistent texture given the print was basically “floating”. Rather than one side having the texture of the plate and the other the normal print texture.

Edit 2: Added Pictures

I figured I’d also add pictures of the Bambu slicer speed indicators. The first “black” layer has the intended results, created by setting bridge and first layer infill to 10mm/s.

The same settings did not apply to the first layer “t” and the outer and inner remained the same as the rest of the print. I could change those as well, but that affects the entirety of the print and not ideal for larger, more complex prints. The inner portion of the “t” was set to 10mm/s as well (I don’t recall which setting set that).

I also included (but didn’t print this way) setting the support interface to 10mm/s. That only affected the layer region below the “t”. The purple region “around” the “t” is actually the layer below the “t”. The “t” printed first on the subsequent layer before the support material and directly on the purple region of the lower support layer. So the support interface speed affected the lower region of the interface, but not the upper region of the interface.

[T_guttata]

Hi

Thanks for posting. I almost lost trust into the community, because I reported issues in various threads and nombody seems to be interested in the topic.

I understand what you are saying, and I will add it to the initial post. Could you mabybe show a picture of the testprint?

In the meantime I encountered more issues, so I will add as well:

Issue 5) Flushing volume for filament change

If the flushing volume is not high enough you basically make a predetermined breaking point by design in the layer of material change. I did some testing with a testpart and I had to increase the flushing volume to at least 500 mm3 to not severly alter the mechanical properties. In some cases even more might be required.
The current matrix with flushing volumes are meant for color changes, but not material changes. I would therefore propose the following:

• Give the possibility to have a flushing volume which is greater than 999 mm3 (current max).
• Give a possibility to define flushing volume for changes of material type. For instance: if you go from PETG to PLA, it will not depend that much on the color. So, it would be more conveniant to globally set a min flushing volume for changes in material type.

[Verkinix]

In my print, I used a flush volume of 800 mm3 for each change from PLA to PETG & PETG to PLA. Defaults for PETG to PETG. That has been working alright for the test prints I’ve done so far.

[T_guttata]

I don’t think you need that much from PLA to PETG. 800 is quite a lot. This means that for 100 changes you will waste roughly 100g of material! At the moment I will try with 500 (PETG->PLA) / 200 (PLA>PETG).

I’m still a little surprise the topic has such a low resonance…

[Verkinix]

Agreed, I’ve been watching the flow when it’s flushing filament and 800 seems excessive for what’s needed. The opposite filament appears to be properly flushed, as you said, about 500 PETG>PLA & 200 PLA>PETG, so going forward that will probably be more than enough. Will greatly reduce the time as well in prints where this is used.

[Verkinix]

I found a sort of work around. It doesn’t replace the need for a discrete speed generation at the top of the support interface, but it’ll work well enough on minimally complex prints that are generally flat.

I added layer height ranges and adjusted them to affect the layers I wanted. Then I set the speeds for the parameters that weren’t affected by the normal global settings until the whole layer was at the intended speed. It’s a bit time consuming even on a simple print.

There is also an error I encountered when the height reaches the limit and the speed of the inner & outer are changed. Once the error is generated, clearing it basically requires you to close bambu studio. Performing a subsequent slice will begin the process and ultimately crash to desktop.

In any case, I hope this helps someone trying to do the same. I also hope that Bambu devs put in the aforementioned speed control.