Printing Order Of Mutiple Objects

[gr5 2,177]

It is?  I thought the scan line thing was wrong and the order placed idea was the correct one.

[gr5 2,177]

On 12/22/2022 at 4:05 PM, rachael7 said:

I just don't understand why we still don't have it after all these years.

I think we do have it.  Read above.  It's the order you load the STL files.  At least it used to be.  I'm pretty sure it still is.

[h52WHA 0]

4 minutes ago, gr5 said:

It is?  I thought the scan line thing was wrong and the order placed idea was the correct one.

3d printers (or at least my ender 5) do not see the objects in the same way we do. they have to think in grids alongside your preferable settings (temp, speed, nozzle travel inside only etc.) but that's per each flat shape they have to do in the layer. and theyll work from the nozzle home to the opposite corner. so to manipulate its algorithm you need to understand how its going to calc the next way point( x,y or y,x ). then adjust. I'm satisfied with how mine turned out, just kept moving the one i wanted to go last further out of order and the one "next in line". just keep clicking away till it works in the order you want. 

[rachael7 73]

On 5/15/2023 at 9:18 PM, gr5 said:

I think we do have it.  Read above.  It's the order you load the STL files.  At least it used to be.  I'm pretty sure it still is.

 

That doesn't really give us the ability to control though, if we're honest. Yes, you remove all the items from the build plate and load them again, perhaps; but what if you've already done a fair amount of prep work on the parts? Added per-part settings or support blockers, or other changes that you'd have to redo completely if you deleted and re-added the parts. I reject that as a "solution" - at best it is a workaround - but it is a clunky workaround that really isn't practical in daily use, especially when the proper solution should not be difficult to implement.

Edited May 25, 2023 by rachael7

[Cuq 198]

In version 5.3 (maybe it has changed since the previous versions), the printing order is different if you are in the mode :
All At Once or One at a Time

 

In the One At Time mode, Cura uses the reverse order of the objects list  to print the parts. In this mode you can define the position of the parts on the bed to organize the printing according to the position you want.

 

In the All at Once mode, it starts (for a square bed) from the first part in front of the bed on the Left and the following order will be based on the shortest distance between the parts. In this case it is difficult to define an order of printing except to arrange the parts with a distance which imposes the order of creation. But it is very complicated.

[terory 0]

On 5/16/2023 at 4:18 AM, gr5 said:

I think we do have it.  Read above.  It's the order you load the STL files.  At least it used to be.  I'm pretty sure it still is.

It's a side effect, not the feature. When you open multiple files at once, they will get ordered randomly, most like whatever manages to load first.

 

There is already the object list on lower left corner, I don't understand why cannot we drag and drop to re-order them.

[terory 0]

2 hours ago, Cuq said:

In this mode you can define the position of the parts on the bed to organize the printing according to the position you want.

What does this even mean, yes you can move the objects around on the build plate, but that doesn't solve the problem.

[Cuq 198]

Well, it depends: If we talk about printing order, there are two different needs. One is often in One at Time mode where you want to control the order and position of the part to avoid collisions with the Z axis or displacements for part with similar size. In this case we can solve the problem.

In the second case, we want to have a specific order, for example, to make the small parts first because they do not interfere with the printing process and then launch the largest part at the end of the printing process. In this case it's more complicated because the order of the list will define the printing order. In this case one of the solutions (of Workaround if you prefer)  is to save the models to be made first in a project (3mf file) and the others in a second project.  Then you open the 3mf file  of the parts to be print at the end, and import in this project the first element as model. In this way your modifications, support and other specific parameters defined for every models are preserved and the order is defined.

 

I rarely use the One At Time mode, but if I had this problem and had to reorganize my objects oftently, I think a Macro or a Plugin could automate this process.

Edited May 25, 2023 by Cuq

[jackharvest 4]

8 Years in, and still no proper way to change the object list order (AKA, the print order of objects in One at a Time mode).

 

I print clips. An EFF ton of clips. I have to print them one at a time in case of failure (better to have some finished products than screw up the entire batch). I've painstakingly re-arranged the models in reverse-loaded order. It works. Its ok.

 

Preferably though: We have a window (like photoshop has "layers") full of "objects" and we just drag and drop them up and down the list until they are in the order of printed preference. Or, add it to the context menu. Or, have it be a clickable window that only appears once the "One at a Time" print sequence is selected. Or, go back to the OLD way from 5 years ago where it was order "scanned" from left to right -- even that made more sense than loaded object order.

 

Please, please reconsider this ask.

[rursache 2]

i'm here to chime in about the absurdity of the lack of rearranging the object order in cura (5.6 at this time).

just let me redrag the objects in the object list...

[Slashee_the_Cow 274]

I'm sure I'm going to regret sticking my hand up like my teachers got sick of me doing, but if you want to print in grid/rows/columns and have them done in order (i.e. top left to bottom right) it might be possible with a postprocessor reordering the sets of layers, but that isn't going to work for an arbitrary order.

 

If you're just doing a few things you can always edit the gcode by hand. If you open the gcode file in Cura you'll see the order it's printing them in, so just open the gcode file in a text editor (my favourite on Windows is Notepad++) and move them around yourself. Technically you can do that for a lot of things, but if you try that, things get confusing real quick.

[smallpony 2]

Just chiming in that I'm also dismayed that we cannot specify the print order of parts.

I have tall parts and short parts, and no matter which order I load them in, CURA always reduces the build volume height below that of the taller object, and the slicer fails to slice it.  There would be no problem printing the short part and then the tall part, but it always seems to assume the worst case.  Loading the STL files in a different order makes no difference, nor does rearranging them on the build plate.  Too bad there's no "build sequence #" property that could be edited, or at least an east-to-west or north-to-south ordering that could be used to have your tall parts printed after the short ones.

[rachael7 73]

Where this really bites me on the butt is when I build custom supports for complicated parts. The supports are drawn in CAD, as separate objects, imported to Cura, and set to print as support.  The workflow functions fine, but since it is a print all at once mode, the order in the list makes no difference, and because all the supports have to be in a specific position, I cannot move the parts around the plate to get them to print in the order I want. As I mentioned previously, this significantly impacts the quality of the part due to extra crossing of the perimeters and the associated flaws (made more obvious because I'm printing in clear material). There is no workaround and no alternative that I can find or that anyone can suggest. Manually specifying the print order is a feature that needs to be implemented. Pretty please?

[Slashee_the_Cow 274]

1 hour ago, rachael7 said:

Where this really bites me on the butt is when I build custom supports for complicated parts. The supports are drawn in CAD, as separate objects, imported to Cura, and set to print as support.  The workflow functions fine, but since it is a print all at once mode, the order in the list makes no difference, and because all the supports have to be in a specific position, I cannot move the parts around the plate to get them to print in the order I want. As I mentioned previously, this significantly impacts the quality of the part due to extra crossing of the perimeters and the associated flaws (made more obvious because I'm printing in clear material). There is no workaround and no alternative that I can find or that anyone can suggest. Manually specifying the print order is a feature that needs to be implemented. Pretty please?

If you're setting them as supports, they'll always print before anything else on that layer. Support is always the first part of a layer to print.

 

On 2/13/2024 at 3:37 PM, smallpony said:

Just chiming in that I'm also dismayed that we cannot specify the print order of parts.

I have tall parts and short parts, and no matter which order I load them in, CURA always reduces the build volume height below that of the taller object, and the slicer fails to slice it.  There would be no problem printing the short part and then the tall part

I'm a little late here, but you can change the height boundary by going into the printer's settings and increasing Gantry Height (it's supposed to be the height between the nozzle and the bottom of its gantry to make sure just moving around the plate doesn't knock something already there over):

Unfortunately I can't help you with the printing order part of your problem.

[rachael7 73]

5 minutes ago, Slashee_the_Cow said:

If you're setting them as supports, they'll always print before anything else on that layer. Support is always the first part of a layer to print.

 

 

That isn't the problem. The issue is that because the supports are separate objects in Cura, it doesn't print the supports in any reasonable order. Imagine there are two rings of supports, one inside a vaguely ball-shaped object, and one ring outside. It makes sense to print all the inside ones or outside ones first, then cross the part once to print the other set. That minimizes strings and marks crossing the walls of the part. But what Cura does instead, no matter what I try, is alternate back and forth, one inside then one outside, so it repeatedly crosses back and forth over the walls of the part. I minimized damage as best I could with z-hop and retraction settings, but the material (PMMA) was an especially stringy one and all the strings getting dragged across the part negatively affected the clarity. I went round it for days, there simply is no solution other than manually editing the g-code, without an option to set the print order.

[jeroent 4]

Hi guys, 

 

I ran into the same issue; wanting to print one-at-a-time and finish the parts from the front of the buildplate to the back. 

 

At first i also noticed that cura 5.5.0 randomized the printing order, often choosing the objects in the back first. 

I tried messing around with upload-order, last-moved-order, offsetting the parts left and right of each other. all to no avail.

 

Then i noticed it preferred to print the part which has no overlap with the toolhead-dimensions of the other part (the gray square indicating the X+, X-, Y+ and Y- dimensions of the head).

In my case my head has more overhang on the front than back, thus causing it to prefer to print the back parts first. 

 

So i found this workaround: 

Since i want to order my parts front to back, the only Head-dimension that counts is the Y+ so the head does not collide with the printed part in front of it.

 

i set the dimension Y- to the size of my Y-axis. 

This causes the head-dimensions gray area behind the part to always be overlapping the next part, since it will not print the part in the area gray first and since all parts behind the first part are in the gray area, it will print the front part first. and it will do this for every subsequent part. 

As long as there is a side of the part that is not overlapping a gray area ( so in this case in front of the part you want printed last) , the slicer can slice it. 

 

This principle should also work to determine a order in X.

 

I hope this makes sense and can help some of you to find some order in this madness 😄 

[GregValiant 1,260]

I must have looked at arranging the parts a hundred times and this never occurred to me.  It works!

I wish I could award you with something more than an emoji, but it will have to do.

But I'll throw in a couple more cuz, ya know, they're cheap.

🏄‍♂️🍺🌴💐🎺🤓

Edited March 7 by GregValiant

[DivingDuck 105]

Not the solution I would expect but hey, we take what ever we get that helps for an never solved problem - even a not intended behavior as workaround.

Great finding, thanks for showing it!

[Cuq 198]

A PR have been merged last month to solved this problem : https://github.com/Ultimaker/Cura/pull/17893 

But haven't seen yet this function in the existing alpha or beta.

[GregValiant 1,260]

Wow.  53 files involved.  It addresses feature request #4835 which dates to Nov 19, 2018.

 

@Cuq - Does this qualify as "The development dynamic is more active on other slicers"?

Edited March 7 by GregValiant

[Cuq 198]

@GregValiant  🤣

Even more, if you consider that in addition to selection by user order, you can also sort by object position or Z Size.

Edited March 7 by Cuq

[gr5 2,177]

I marked @jeroent as "the solution" even though obviously it's not the perfect solution - it is by far the best I've seen at this point.  Hopefully it's all moot when the next cura comes out.

[rachael7 73]

3 hours ago, gr5 said:

I marked @jeroent as "the solution" even though obviously it's not the perfect solution - it is by far the best I've seen at this point.  Hopefully it's all moot when the next cura comes out.

Please remove this marking. It is at best a workaround, not a solution. It also doesn’t address the case of all-at-once printing. Marking it as a solution gives the false impression the issue has been resolved, when it most certainly has not been resolved for me and others printing in the more common all-at-once mode. 

[Slashee_the_Cow 274]

3 hours ago, rachael7 said:

it most certainly has not been resolved for me and others printing in the more common all-at-once mode

I haven't run a poll, but I would wager that for anyone printing multiple discrete objects that one at a time is the preferred choice.

[GregValiant 1,260]

As the self-proclaimed "King of Workarounds" I have the utmost respect for the fabulous work of @jeroent and I vote that the "Solution" tag stays.

Of course if 5.7 is released tomorrow, it will be a very short term in the limelight but well deserved nonetheless.  Prior to his discovery we had random randomness.  Now there is an excellent chance at organized randomness.  Ya gotta love progress.