[BUG]Filament change in sequential print - collision with earlier print

[MechanicalCat]

Apologies if this is a duplicate - I searched all issues open/closed for "sequential" in title and only found a handful, none related. Did I do my search wrong?

If filament runs out during a "print objects sequentially" print-run, then the head moves to X=max and the bed moves to Y=0, ready for new filament to be inserted. Z doesn't appear to be significantly changed during this move.

This means the head collides with any earlier-printed object which is in the way and which happens to be higher than the current layer.

[Prusa-Support]

Hello! Sorry for the issue. Was this with FW 3.11.0 and Prusa Slicer 2.4.2? Can you please send me an example GCode and 3mf file of one of the models where there was the error? We'll look into this!

Alessandro Pantaleo Prusa Research

[Prusa-Support]

Hello @MechanicalCat! Following up on this thread, I found more information about this.

At this moment the firmware on the MK2.5/S and MK3/S/+ stop procedure is: SD card print Z is lifted by 10 mm of current position This would mean if the previous print is higher than 10mm it may crash into it. Moves to cancel position with is X=50 and Y=150 both axis moving at the same time.

Host/Octoprint print
    If Octoprint is configured correctly then it behaves the same as it sends M603 Gcode command to the printer and does 
    the same as with SD card print
        Octoprint Settings -> GCODE Scripts
            After print job is cancelled ==> M603
            After print job is paused ==> M601
            Before print job is resumed ==> M602
    If Octoprint doesn't have the configuration above
        It probably just stops above the print.

Example where it would likely fail: 1st print is at X=50 Y=190 and is 20mm tall 2nd print is at X=100 Y=140 also 20mm tall 3rd print is at X=150 Y=90 also 20mm tall

A workaround could be to arrange the prints differently. 1st print as close as possible to x=250 and y=0 2nd print clearance distance behind and left and so on.

Still, feel free to send me the 3mf file (https://help.prusa3d.com/article/saving-projects-as-3mf_1773), let me know if we were in the SD card or Octoprint case and if rearranging the objects would solve the issues!

Alessandro Pantaleo Prusa Research

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[ulab]

This is still something that should be looked at. :)

[MechanicalCat]

If the above statement that "Z is lifted 10mm from current position [and then the head moves to (250,0) ]" is correct, then... if (say) the filament runs out when the head is at 0.5mm on the second or later object, then the head will sweep a line across the deck and only about 10.5mm high. Which means the head (or the lower X-rod) is likely to collide with something almost irrespective of the order the items are arranged on the bed. Seems like Z should move to an absolute position which is calculated to be higher than any position reached during the current print-run (so far). Or (even simpler) just don't move the X/Y position at all.

[Prusa-Support]

PrusaSlicer wants all objects to be below the extruder clearance height except for the last object, which can be as tall as the printer's max Z. [...] The collision detection logic is pretty basic and will sometimes prevent you from Exporting printable G-code. It's up to you to take responsibility and increase the height tolerance.

https://help.prusa3d.com/article/sequential-printing_124589

In other words, all objects should be within extruder clearance height - except the last one. The extruder clearance height should normally be set as the Z distance between the nozzle and the lower smooth rod.

I didn't reproduce all print scenarios myself but, theoretically, if

• the objects are within extruder clearance height (except the last one),
• don't overlap in extruder clearance radius,
• don't share the same X or Y coordinate,
• are distributed diagonally from front-left to rear-right,

there won't be a collision - not even if the filament runs out after the first object is completed because the nozzle will move in the other (supposedly free) direction and the lower rod will move above any (necessarily small) printed object.

The stock clearance values in our pre-sets are probably intentionally tighter than necessary but that's for safety reasons. If there are that are uncovered print scenarios, please share a 3mf/gcode and a videos of them for us to review. This should probably be discussed in Prusa Slicer's repository though.

If you modify our pre-set clearance height or radius, please do it at your risk and do your best to avoid print interruptions.

If your suggestion is about changing the Z height during a filament change then please check/follow other more specific issues and pull requests about this (e.g. https://github.com/prusa3d/Prusa-Firmware/pull/2875, https://github.com/prusa3d/Prusa-Firmware/issues/3532, https://github.com/prusa3d/Prusa-Firmware/issues/4115, https://github.com/prusa3d/Prusa-Firmware/issues/4344).

Can this issue be closed?

Michele Moramarco Prusa Research

[ulab]

"don't share the same X or Y coordinate" and "the objects are within extruder clearance height" reduce the size of objects quite a bit to a point where sequential printing doesn't make much sense anymore.

Filament runout is also not the only case where this can become an issue. See #3623 for example.

It looks like @3d-gussner has assigned this to himself and is working on it? I am not sure why you want to close it now?

[3d-gussner]

@ulab

It looks like @3d-gussner has assigned this to himself and is working on it? I am not sure why you want to close it now?

I like the idea that is why I assigned myself to this issue. Not sure if and how fast we can implement it.