Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support interface/raft additional settings #14186

Open
Trapperdude opened this issue Feb 22, 2025 · 0 comments
Open

Support interface/raft additional settings #14186

Trapperdude opened this issue Feb 22, 2025 · 0 comments

Comments

@Trapperdude
Copy link

I find myself frequently having to design in my own support interface because of a slicer limitation where I can only have a set material for the raft/interface, and the body of the supports.

I'd like to see optional intermediate interfaces included as a slicer setting. The settings for support interface layers should be listed from bottom to top of vice versa.

I'll give several example of where this setting would be useful and hopefully said examples will make it more clear what exactly I am asking for here.
Example 1: I assemble my ABS parts with a one or two layer thick slab of PLA under them to prevent warping (it's very effective so you'll have to try it if you haven't already). This is all well and good and I can use a raft setting to this end. However, I also do this with nylon to a greater extent. I print nylon with ABS supports. This is, however, a low temp nylon. The bed temp required for the ABS is too high to prevent my nylon from curling and my ABS won't stick to the bed well if I lower it. So I put the ABS supports on a PLA raft. This introduces two problems. The first is that the raft and support materials are not individually selectable, so this means I need to create the raft manually as another part and then assemble it together with my main part. The second is that nylon does not stick to PLA. This is remedied by including yet another raft of ABS on top of the PLA raft. Now the solution is complete and the print will execute correctly.

Example 2: The support material and body material exhibit different adhesion properties dependent on printing order. A on B is a good bond, but B on A does not stick. I have encountered this when using one CF material and one unfilled material I believe it was PETG-CF and ABS, but it could have been PETG-CF and HIPS or Bambu's support for ABS. I am unsure. In our example, though, the support material is very expensive. I cannot print the support material onto the base material, which means that I would need to print the whole support out of the expensive support material or use a different material for the body of the support. It also means a different support material for a bottom interface would be required if I had said interface enabled. This is not something the slicer supports.

Example 3: This one is quite a bit more niche, but I'm sure we can all agree that saving money on filament is a good thing. Ranked most to least expensive, you have filaments A, B, and C. A will stick to B (as a breakaway or soluble) and C, but B will not stick to C. A and B are engineering filaments, while C is PETG or some other cheap filament. A great way to handle this and save money when you have a large support material expenditure is to have top to bottom Part, Interface X, Interface Y, Support. In other words, material A, B, A, C. The ability to define multiple interfaces will permit you to migrate to other cheaper (and faster printing) families of materials on a tool changing printer like the XL and save money and time.

The only clear alternative is to design in the interfaces manually, which is tedious and arguably less effective depending on the complexity of the part.

The situation in example 3, I should point out, is not a hypothetical. It's a situation I experienced using a composite of TPU and nylon as a intermediary material between pure TPU and nylon in a print alongside PVA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant