Suggestion: use non-critical MCU code (akin to Danger Klipper) to allow removable MMUs

[k1-801]

Why

MMU, by design, is an optional part of the printer. MMUs are typically connected over USB, which is not only meant to be easily disconnected, but is also known to be unreliable at times. However, the current implementation with MMU registered as a full blown MCU, mandates that the MMU remains connected at all times. If it is not connected, the printer will not start with the existing config, and if it loses communication for a fraction of a second during print for any reason, the whole machine would go into shutdown.

How

The Danger Klipper project has faced a similar case with removable accelerometer boards, and they implemented a feature known as "non-critical MCU". That allows to declare an MCU, which will not cause a critical error if the physical MCU cannot be found or loses communication.

I believe, some of the related code can be ported into Happy Hare, so that the printer can initialize without the MMU, and, if needed, connect to it later. Ideally, it should also be able to continue printing if MMU temporarily disconnects, with a warning that the encoder functionality would not be available until MMU reconnects, and the toolchanges will work as a PAUSE command. It should have a similar effect to how MMU_ENABLE can disable the whole functionality, but only temporarily, without making changes in the files and without resetting the stats - so that it can bounce back immediately when the MMU reconnects.

I'm not sure if the Danger Klipper's implementation seeks to re-connect to such an MCU or not, but, if this is to be ported to Happy Hare, the ported version should do so..

Alternatives

There is also an alternative approach to this, which is to have a daemon that checks the location of the MMU from the config and monitors it's presence in the filesystem, and then if MMU is missing (or if it disconnects), swaps the MMU support include in printer.cfg with a replacement file that declares placeholders for macros, so that setting variables in them doesn't cause errors, and so that toolchange macros work as a PAUSE - and then restarts Klipper as needed (and if not actively printing at the moment; if MMU disconnects, it should let it crash on it's own).

[k1-801]

Can potentially make #359, #269 less dangerous, if it's caused by a communication error only (this change won't exactly solve the problem but at least would allow to continue the print).

I myself have run into a similar problem with "Lost communication with MCU" over USB, and it turned out to be more than one simultaneous issue. Sometimes, this error was caused by MCU shutting down due to a drop in power on 5v bus, caused by the servo movement (thanks Fysetc for NOT including a single electrolytic capacitor on their ERB v1 in the 5v power regulator which has a SERVO on it ffs), and sometimes it was a USB cable coming loose somewhere inside the printer - and the cable issues were hiding the MCU power issue for a long time.

How did I find out these scenarios are different? The MCU always goes into a brown-out shutdown every time the error was caused by the servo, from which it can no longer be reset by firmware (requires a full power cycle or a press on RST). And after replacing all USB cables with a really high quality one, I noticed that now after such an error it always stops in the parked position and never over the printed parts.

Having a feature as described above could have helped to reduce the consequences and to track the existing issues sooner, as it would come back online if it was a cable issue and it would NOT if it was an issue with the board itself.

[k1-801]

Source:
https://github.com/DangerKlippers/danger-klipper/pull/339

[moggieuk]

This is an interesting idea and certain in the category of make the software bullet-proof ... something I want to concentrate on now that pretty much all the min functionality I want is complete.

This thing I I'm not sure the can be implement or should be in Happy Hare. I can see it being an option when setup on Danger klipper but really there is nothing that requires HH / MMU to use an single external mcu. It would partially be controlled from the master mcu or multiple mcus.

I will look deeper into the concept though.