Support Interface slicing bug: Extra interface placed improperly in middle of support structure, causing print failures

[psiberfunk]

Bambu Studio Version

1.7.0.65

Where is the application from?

Bambu Lab Official website, Bambu Lab github releases

OS version

MacOS

Additional system information

No response

Printer

X1C

How to reproduce

Open Attached 3MF project file. Slice.

Notes:

• Manual painted supports are being used to isolate this bug, and I have ensured the only part selected for support is the overhang. Nothing in the area of the bug is supposed to be supported.
• This happens with multiple versions of the slicer. Also happens in the Orca fork, but I reproduced here as well.
• Here, I use black as the interface layer to make it easy to see the glitch.

Screenshots

Actual results

Screenshots here show what happens with the slice, and that the actual print also does this, improperly. Because this interface layer is intentionally weak it causes the whole support to break and the print to fail.

Expected results

The slicer should not be generating an interface / filament switch at this point in the support. This is clearly a slicer bug.

Project file & Debug log uploads

Project file attached.

Log file N/A because this is a slicer logic bug. SupportInterfaceBug.3mf.zip

Checklist of files to include

• [X] Log file
• [X] Project file

[psiberfunk]

@tangketan do you require any further details ?

[tangketan]

@psiberfunk This is actually not a bug. We have a rule that support material can't be in the support base. Any other material is allowed. This is to ensure the color changing is minimized. Set the interface filament to any support material and you'll see everything is fine.

[tangketan]

If you want to use a non-support material as interface, there are two ways:

1. enter develop mode, set Support material in the filament setting

2. specifically set the filament of support base

[psiberfunk]

@psiberfunk This is actually not a bug. We have a rule that support material can't be in the support base. Any other material is allowed. This is to ensure the color changing is minimized. Set the interface filament to any support material and you'll see everything is fine.

How is this not a bug though? it's randomly inserting something other than the default material. The need to set it to a "support" material that's defined explicitly as a support is kind of silly and totally not clear to the user at all. It clearly forces the user to think way too hard and clone a material profile.. or set it explicitly.

It's not at all clear that you should have to set the base/raft material explicitly here. I would suggest that the "default" needs to be changed to "Any filament allowed" to be clear to the user what's going on. As it is, it's not at all clear.

[psiberfunk]

Furthermore, while "any" is reasonable when the materials are the same TYPE of filament.. when they're different filaments like PETG vs PLA, it's clearly always a bad idea and should be prevented. I still maintain the behavior as it is is a bug that will lead to print failures.

The slicer should KNOW that two different material types (not color!) are unlikely to bond well together, just like it warns the user about plate and other material compatibility issues.

[psiberfunk]

If you want to use a non-support material as interface, there are two ways:

1. enter develop mode, set Support material in the filament setting
   ![image](https://user-images.githubusercontent.com/13730459/254747160-2b3ec969-0c44-429e-8c2c-98d46b16411a.png)

2. specifically set the filament of support base
   ![image](https://user-images.githubusercontent.com/13730459/254747286-e5abea33-7fd0-4121-8282-a2e9530e375e.png)

Having to use develop mode isn't a valid fix. Fixes should not be buried behind developer options, from a UX perspective. The other fix is valid but completely obtuse and not at all easy to discover. The slicer should know better, and it's EASY for the slicer to know interspersing material A in the middle of a support made out of material B is a bad idea. It's almost always a bad idea.

Asserting that this is not a bug is like Steve Jobs telling iPhone users "you're holding it wrong". Maybe technically correct, but tone deaf to the user experience that many many users will blindly run into and have no idea how to fix.

[psiberfunk]

P.S. If you've decided, despite my logic above, not to fix this, you should close with "won't fix". My recommended solution is to:

1. Relabel "default" to "Any color PLA/PETG/etc"
2. Change the code to force the support filament (within the main support body) to stay the same TYPE (PLA, PETG, etc).
3. Do the same as 1. & 2., but for also for the support interface, as well.

Doing these things will prevent users from running into this problem and failing prints without a clear understanding as to why.

[tangketan]

By "not a bug" I mean it's totally following the design purpose, not saying it's optimal. And I do agree with some of your suggestions, which would certainly make things clearer. I'll discuss it with our team.

[jennyy867]

I'm experiencing the same issue, and ran through probably two rolls of filament before realizing it was the slicer update that changed. I have since had to roll back to an older version to keep printing for my business. I'm seeing the extra support interface not just on trees as the image above, but a whole interface layer in PLA on my model before the true support interface starts with Support for PLA. These filament lines cannot be removed making my models unsellable.

Is there a reason this cannot be changed back to the functionality before the update? Or a timeline for a new release? I'm not able to use the new calibration features, which is a bummer, until this is resolved in a new release. This works properly in Bambu_Studio_mac-v01.06.02.04. and I confirmed today it is still broken in Bambu_Studio_mac-v01.07.04.52.

[jennyy867]

And I changed it to white (model is usually black) so you could see, but it may be confusing since the support color is white. Here's the model sliced in blue with white support interface as well so you can rule out it working but looking the same color in the slicer :)