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

Allow user-defined print order prioritization in the per-model settings #19693

Open
tremitry-darkstar opened this issue Sep 27, 2024 · 3 comments
Labels
Status: Triage This ticket requires input from someone of the Cura team Type: New Feature Adding some entirely new functionality.

Comments

@tremitry-darkstar
Copy link

tremitry-darkstar commented Sep 27, 2024

Is your feature request related to a problem?

I have some models to print that have long, thin surfaces that need to adhere to the buildplate. I created a bunch of rectangular models within Cura, using support blockers that I then changed into normal models, that are one layer thick to act as brimming at the very end of these lines so that the ends have something a little more solid to stick to (using regular brims would have been a giant issue to remove - I already tried that with these models). Unfortunately, Cura printed only half of these rectangles before starting to print these lines (see screenshots below). Since the surfaces I'm interested are long and thin, it would be better to have my custom brimming printed first so that these long thin surfaces have something to attach to and help improve adhesion at the ends.

Describe the solution you'd like

Allow a per-model setting that allows users to define printing prioritization when laying layers down. This would have allowed me to set these rectangles to be printed before the models I'm actually interested in, just like regular brims.

Describe alternatives you've considered

Since my specific problem I was trying to solve was creating a custom brim, adding a new per-model setting somewhere that allows models to be printed as build plate adhesion types - primarily as "brim" or "raft". Or some other clever way for users to define custom brims/rafts to their models. A common solution some people use is to create "mouse ears" or "lily pads" within their modeling software, so having the capability within Cura to create some real custom brims would be quite useful and even more flexible since brim settings can be adjusted.

Affected users and/or printers

Everyone who has models to print that might benefit from creating some custom brimming/rafting. Or users who would prefer to configure which models the printer should prioritize laying material down first for whatever reasons.

Additional information & file uploads

image
image
image

@tremitry-darkstar tremitry-darkstar added Status: Triage This ticket requires input from someone of the Cura team Type: New Feature Adding some entirely new functionality. labels Sep 27, 2024
@GregValiant
Copy link
Collaborator

I print a lot of PETG and long skinny models are always a problem. I don't know if your suggestion would solve the problem. The root problem is that Cura considers the separate pieces as separate models.

This is a model with a support blocker configure to "Print as Part". You can see that Cura treats it separately from the main model. In this example the little block does print first and doesn't really act like a brim because it is a separate model.
image

If I set the block up where I want it, then select the "File Export" command and export the Cura build plate as an STL file then the block will become part of the main model in the new STL.
I clear the build plate and when I bring that new "combined" model into Cura it will slice like this because there is only a single model as an STL file can only contain a single mesh.
image

Cura can do some things with models, but it isn't a CAD program by any means. Configuring your model and the anti-warp tabs as a single piece will fix the problem. An app like MS 3D Builder is good at this sort of thing.

For this model, I designed the tabs into it in CAD because I needed them 1mm thick. I added a chamfer where the tabs meet the model so they would be easier to cut off.
DSCN2809

It was pulling hard and those big tabs almost weren't enough.
DSCN2814

@tremitry-darkstar
Copy link
Author

I have used Cura to merge models previously and then exported them into a single STL file before. That's not really what I'm trying to do here. I'm comfortable with Cura printing the "Print as Part" support blockers as separate models. All that Cura needs to do is know to print those parts first when necessary. When they're printed first (and with good adhesion), then the long, skinny pieces that get printed afterwards have something for the ends of the print to stick to and are less likely to lift off the build plate. There also might be other situations where a user might want to prioritize certain models to be printed first.

This feature also kind of already exists, but is gated behind Print Sequence being set to "One at a Time". All that would really need to happen is to make the Set Print Sequence Manually checkbox available regardless of the Print Sequence setting.

@tremitry-darkstar
Copy link
Author

An alternative for my specific use-case would be to add a new "blocking" model mesh type as "brim" and Cura would treat it as such. So, it would print it first like it does with brims in general, and it would inherit all of the brim-related settings that the active profile would have set. The mesh type can already be configured to "Print as support" so there is some similarity with existing functionality already. And maybe that would be more useful to people in general than configuring the print order (I haven't been 3D printing for very long, and I'm just a casual hobbyist), but I am assuming that enabling a user-defined print ordering would have more appeal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Triage This ticket requires input from someone of the Cura team Type: New Feature Adding some entirely new functionality.
Projects
None yet
Development

No branches or pull requests

2 participants