[BUG] XL multitool can move active tool into parked tools after a collision causing damage

[tg73]

Printer type - XL multitool

Printer firmware version - 5.1.0 release (original)

Describe the bug If collision detection is disabled (which it is by default, and must be disabled for input shaper), the XL can experience collisions leading to significant XY position misalignment, and can then drive the active tool into the parked tools with significant force causing damage.

How to reproduce Any print which can lead to a collision, for example see #3578.

Expected behavior The XL should not be able to move the active tool into the parked tool area except when performing tool change operations and when in a known pre-homed, collision-free state with accurate XY positioning.

Comments The XL now has input shaper (IS) as a release feature (FW 5.1.0, PS 2.7.0) and so Prusa is is actively encouraging and sanctioning its use. However, crash detection must be disabled, and is disabled by default. This means that there is no protection against the active tool being driven with force into the parked tools due to misalignment after a collision. I'd suggest that the XL should either require that collision detection is enabled, or it should have an additional safety sensor that detects when the y carriage moves into the "tool change operations only" zone. This would allow the firmware to detect dangerous movement during normal print operations and then take appropriate action. The additional sensor could be for example a hall effect sensor attached to the chassis with a magnet on one of the y-carriage parts. Even if collision detection is enabled, the additional sensor would provide a second line of defence against the printer damaging itself due to an undetected collision. As far as I am aware, this is the first Prusa printer that has been able to damage itself like this, so a different attitude towards disabling crash detection is needed. For example, the worst that will happen to a MK3 after an undetected collision is hitting an endstop.

[tg73]

Here you can see an example of the force involved and the kind of damage that can result (in this example, all tools were parked, so the damage was to the toolchanger itself).

Here are some contact point examples (posed by hand when the machine was powered off):

[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.

[tg73]

Waiting for Prusa to respond.

[github-actions[bot]]

Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.

[danopernis]

@tg73 is this actual bug with actual reproducer, or are we just speculating here?

[tg73]

@danopernis The link in a previous comment shows the real-world damage made to the toolchanger head by a dock collision. It therefore seems logical to assume that damage could result to a loaded toolhead. Here is a video showing the toolhead crash into the dock after a layershift (not my video, just from yt searching). Note the camera shake from the force of the collision.

[Prusa-Support]

Thanks for reporting.

This seems nothing but a case of physical collision or layer shifting, where additional features may partially improve the current situation if implementable at all. However, as already observed on Prusa MK3, recovery features like axis collision are often helpful, yet only backup options that are not 100% reliable. The only truly reliable way to print safely and preserve the hardware is to catch the problem and work on it in order to remove any chance of layer shifting and axis collision. This may be possible through considered troubleshooting steps - > https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3578#issuecomment-2334673436.

Your request is very specific about docking problems in peculiar conditions however, in a nutshell, it seems that your ultimate request is about enabling the crash detection. Please please keep your reports/suggestions as concise as possible. You can enable Crash Detection and this has only little to do with Input Shaper at the current time - maybe the crash detection was only temporarily disabled for specific reasons, but I can't recall. At the current time, this feature is only dependent on Phase Stepping so allow me to clarify.

As per FW 6.0.0 release notes

Currently, if Phase Stepping is enabled, crash detection is disabled. This is due to technical reasons. Developers are investigating whether these two features can work together.

... and this statement may probably address and close this issue.

In other words, if you have a preference, you can disable Phase Stepping and enable Crash Detection, but rest assured that our developers have considered a number of viable options and keep actively looking for more alternatives. However, you may need to test various sensitivity levels and results are not totally guaranteed so this should not refefrain the user from investigating the problem and running troubleshooting, with the help of our Customer Support.

About hardware modifications, feel free to experiment alternative hardware solutions on your printer and to report back your findings based on realist results, especially on the forum to share with the community, or via email (info@prusa3d.com) so we can share with the product managers. This site mostly concerns the firmware.

Michele Moramarco Prusa Research