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

Cannot get 'print in sequence - One at a time' to work #16566

Closed
TheRealOne78 opened this issue Aug 26, 2023 · 12 comments · Fixed by #16596
Closed

Cannot get 'print in sequence - One at a time' to work #16566

TheRealOne78 opened this issue Aug 26, 2023 · 12 comments · Fixed by #16596
Labels
Type: Improvement Improvement to existing functionality.

Comments

@TheRealOne78
Copy link

Cura Version

5.4.0

Operating System

Gentoo Linux (Using AppImage)

Printer

Ender 3 V2

Reproduction steps

  1. Load two models
  2. Go into advanced, type "Sequence" and in the "Print Sequence" dropdown menu select "one at a time"

Actual results

Can't get the objects to slice, even if the objects are in the printing area and don't overlap.

image

Expected results

To be able to slice in sequence.

Add your .zip and screenshots here ⬇️

CE3E3V2_Z_Stabiliser.zip

@TheRealOne78 TheRealOne78 added Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Aug 26, 2023
@GregValiant GregValiant added Type: Discussion Open-ended discussion (compared to specific question). Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Type: Bug The code does not produce the intended behavior. Status: Triage This ticket requires input from someone of the Cura team labels Aug 26, 2023
@GregValiant
Copy link
Collaborator

Thanks for the report and the file.
In your screen shot there is a warning box at the bottom. The first line says that the model must "Fit within the build volume".

In "one at a time" mode the "Machine Print Head Settings" come into play as a safety so the printer can't crash into a print. The gantry height for your printer is 25mm and the model is 40mm tall so your model doesn't fit in "The build volume".

This is expected behavior so I'll remove the bug label and close this. I hope you understand.

@TheRealOne78
Copy link
Author

I see how it works now.

However playing around I've noticed yet another thing with Sequence Printing.

Having just one tall object with "print one at a time" on and no "modifiers" would print fine:
image

However in this example, if I put a "no support" modifier block, it would treat it as a separate object:
image

I'd expect it to treat it as part of the object. Same would go for other modifiers, like support, normal or overlap, if two or more objects form one object.

CE3E3V2_Z2_Leadscrewbracket.zip

@GregValiant
Copy link
Collaborator

Your expectations are incorrect.
The model is a "Mesh" and the blocker is a "Mesh". With multiple meshes on the build plate the Gantry Height is enforced and one of your meshes is too tall.
You could adjust your Gantry Height in the Machine Settings but you have to be very careful. Any movement that would occur across the top of a completed model could hit the model and cause the model to break loose, or the build plate to shift.
If you have a Pause or filament change in the file and are parking the head it might move across a completed model and hit it.

There are certain situations (like the staggered locations in your first example) where it might work.
The Gantry Height is the distance from the build plate to the bottom of the X-beam and it is a crash point. You always need to keep that in mind if you intend to fiddle with the gantry height.

@TheRealOne78
Copy link
Author

Your expectations are incorrect.
The model is a "Mesh" and the blocker is a "Mesh". With multiple meshes on the build plate the Gantry Height is enforced and one of your meshes is too tall.

That would imply that the x-gantry would have to lower, however since there's just one overall object (made with multiple meshes) with multiple meshes, it shouldn't affect the X-Gantry.

To give an example, the "Eraser" mesh would just erase some of the support blocks from the main object. It doesn't lower the gantry at all. That would apply the same to other modifier meshes, if they are attached to the main object.

Also meshing two object into each other it should print them at the same time, as the same object. That should also not lower the X-Gantry.

In terms of implementing this, it would be rather difficult, and this approach already works with "All at once", so I suggest adding a reminder for the end user that "One at a time" is on and this issue would be solved by switching to "All at once". This would imply that there's one overall object - either simple or merged with other objects - and not more separate/unmerged objects.

@GregValiant
Copy link
Collaborator

It's the way it works.
In your first example of the two 40mm tall models - they are spaced in such a way that if the left front model prints first then there shouldn't be a crash AS LONG AS there is no movement across the model when the nozzle is down low for the second part. You and I can tell that by looking at the preview. Cura cannot.
In your second example there is certainly no benefit to setting it to "One at a Time".

There is no "AI" involved in this. It's up to the user to know the software and set it up so they get a good slice and print.

@fieldOfView
Copy link
Collaborator

I am in agreement with @TheRealOne78 that Cura not considering if a "second" mesh is a "printable mesh" (ie: not a modifier mesh or support blocker) or not when deciding if the One at a Time mode can use the full height or not. I'll try to see how hard it is to fix that.

@TheRealOne78
Copy link
Author

It's the way it works. In your first example of the two 40mm tall models - they are spaced in such a way that if the left front model prints first then there shouldn't be a crash AS LONG AS there is no movement across the model when the nozzle is down low for the second part.

Yes, I was wrong with my first example, as I did not take the X-Gantry height in consideration. After your first reply, I did.

You and I can tell that by looking at the preview. Cura cannot.

And that's not to be expected in "One at a time":

All at once:
Screenshot_20230828_111138

One at a time:
Screenshot_20230828_111703

Here the XYZ cube is too tall, and cura thinks the support block should be printed as sepparated, which should not.

In your second example there is certainly no benefit to setting it to "One at a Time".

That's exactly what I am pointing out. When the user forgets that "One at a time" is on and it encounters this issue, instead of a hard-coded solution to integrate the modifier meshes as one with the main object, just tell the user to switch back to "Print all at once". It's probably a simpler approach.

There is no "AI" involved in this. It's up to the user to know the software and set it up so they get a good slice and print.

It would be hilarious to put an AI to slice. However a reminder that "One at a Time" is on would be nice.

@GregValiant
Copy link
Collaborator

There is a warning the comes up and it appears to be triggered by adding a Support Blocker when the model is over-size for One at a Time. Maybe @fieldOfView knows what criteria triggers it?
Like virtually all of Cura's warnings it is small and easily missed. The Z of the build volume being adjusted to 25mm is also a clue.
The warning in the screenshot below came up as soon as I brought in the blocker. In this case the block is configured to "Don't Support Overlaps" but maybe it should be allowed to print unless it is configured to "Print as Normal Model" or "Print as Support".
image

@fieldOfView
Copy link
Collaborator

Maybe @fieldOfView knows what criteria triggers it?

The current criterium is "are there more than 1 meshes in the scene?". Cura does not take into account whether these meshes are support meshes, support blockers or modifier meshes, or if the meshes are somehow grouped. It should.

I looked at the code yesterday. It was not a 10 minute fix, but I will fix this when I have a spare hour or so.

fieldOfView added a commit to fieldOfView/Cura that referenced this issue Aug 28, 2023
Cura lowers the available build volume height when more than 1 model is loaded. This count should include grouped nodes as one (since they will be slice as one and thus not affect the gantry), and should not include modifier meshes or support meshes (since support-meshes are always printed with the first model anyway).

Fixes Ultimaker#16566
@fieldOfView
Copy link
Collaborator

The mentioned shortcomings of the "are there more than 1 meshes in the scene" logic are fixed here:
#16596

@fieldOfView
Copy link
Collaborator

It does not seem that the fix will make it into 5.5. But there's always another release after that.

@nallath
Copy link
Member

nallath commented Nov 29, 2023

It will be in 5.7!

@fieldOfView fieldOfView added Type: Improvement Improvement to existing functionality. and removed Type: Discussion Open-ended discussion (compared to specific question). Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. labels Nov 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Improvement Improvement to existing functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants