Printhead clearance polygon ("One at a Time" print sequencing) does not consider build plate adhesion features

[teeter477]

Application Version

5.2.2

Platform

Windows 11

Printer

Creality Ender-3 Pro

Reproduction steps

1. Set printhead clearance dimensions for your printer from within machine settings
2. Load multiple geometry files and position as desired in slicer
3. Select "One at a Time" print sequence
4. Select "none" build plate adhesion features
5. Slice
6. Note lightly shadowed area around each model which is correlated to printhead clearance dimensions set in step 1
7. Select any type of bed adhesion features (e.g. "skirt")
8. Slice (read next step first)
9. Note that the lightly shadowed area around each model did NOT change in size, even though the effective boundary of the object was shifted outwards (in this case, by the skirt distance)

Actual results

Build plate adhesion features do not affect printhead clearance boundaries (for "One at a Time" printing sequence) as set within machine settings.

Expected results

Build plate adhesion features should affect printhead clearance boundaries (for "One at a Time" printing sequence) as set within machine settings. Printhead/model collisions are possible while printing adhesion features.

Checklist of files to include

• Log file
• Project file

Additional information & file uploads

[MariMakes]

Hey @teeter477,

Welcome to the Ultimaker Cura Github 🚀
Thanks for your report 👍 It's super clear. 💪

I don't use one at a time a lot, but in my experience, you are not blocked from slicing if the areas for one at a time slightly overlap.

I'll have to check with the team what the expected behavior is here. 👍
Can you help me understand how this is impacting your ability to use Cura for printing?

[teeter477]

To be clear, this hasn't yet caused me any issues with printing, although I use "One at a Time" sequencing somewhat regularly and can see the potential for this to cause collisions if I use any sort of bed adhesion features.

I also figure this isn't intended behavior, and that it could also affect other people. I'm curious to hear what the team thinks.

Thanks!

[MariMakes]

Hey @teeter477,

I checked with the team and they mention that what you are seeing is intended behavior.

You can still see the brim indication in a darker shadow. The lighter shadow is supposed to be kind of a danger zone for the printhead knocking over something that is already 3D printed. The brim or raft is considered to be low enough that there is no danger of being knocked over, which is why the shadow does not resize.

Do you have an example of a print where you did run into trouble when the shadow did not resize? I believe this decision is made on an assumption, but they would be happy to reconsider if you can prove them wrong.

[teeter477]

Here's an example of a print that would result in a collision as a result of what I reported. Notice that, both with or without skirts enabled, the model obeys the shadows/slicing requirements (and fits under the gantry, but not the printhead) and is sliced without any errors or warnings:

In the skirtless case, this orientation is fine and would print without collision. However, with the skirted case, this would result in a printhead collision with the first cube. The light shadow isn't offset to account for the added skirts, the printhead would still collide with the first cube while it prints the skirt for the second cube.

(Note, I can see the potential for another setting to come out of this - "Skirt on first object only" when multiple objects exist and "one at a time" print sequence is set.)

In the same way that the skirt generates a darker shadow that's offset from the model itself, it should also extend the light shadow.

I've attached a project file with this case. If my printhead settings aren't embedded, they're Xmin/max = -33/33, Ymin/max = -23/35, gantry Z=30. Bed is 233x225x230

BugReport.zip

[MariMakes]

Hey @teeter477,

Thanks for sharing your findings I was able to prove that the printhead would bump into my printjob.

I brought it up to the team to reconsider and, we've added a ticket to the backlog with the intent to improve this.
For internal reference CURA-10307

Thanks for the report! 👍

[MariMakes]

👋 Quick update on our side.

This is resolved in the 5.5 Beta release 🎉 , you can download the Cura version with the fix here: https://github.com/Ultimaker/Cura/releases/tag/5.5.0-beta.1
I'll close this issue since it's resolved.

Thanks again, and please let us know if you run into any other issues 💪