MMU Fails to start when using network share

[addoyle]

According to Moonraker logs, it appears that mmu_server.py is trying to move some gcode files around when starting up, and is reporting permissions errors. This appears to cause Klipper to fail to connect to the MMU.

See attached moonraker.log and klippy.log.

Hardware specs:

• Model: Voron 2.4
• Main board: Octopus Pro
• Host board: Raspberry Pi 4B
• Toolhead board: BTT SB2209 (RP2040)
• MMU board: BTT MMB v1.0

Software specs:

• klipper: v0.12.0-378
• happy-hare: v2.7.3-29-g4569daff
• moonraker: v0.9.3-1

~/printer_data/gcodes is symlinked to /mnt/bsm/Printer/gcodes which is a network file share.

I haven't tried fixing the permissions yet to see if that fixes the problem, but I don't think it's unreasonable to expect that permissions of gcode files shouldn't cause klipper to fail to connect to the MMU.

I'll post a comment once I've confirmed if fixing permissions allows it to start back up.

moonraker.log
klippy.log

[ningpj]

Does the pi user have write permissions to the directory? The moonraker HH plugin needs to process and expand the gcode tokens, rewriting the file as it does.

[addoyle]

To the directory, yes. The files inside it, not always. If it does need write access, that’s not too big an issue. It just seems a little surprising to me that not having write access to few gcodes would crash the system.

[ningpj]

Yes, it needs to rewrite the files so it can expand and convert all the useful HH tokens like MMU_START_SETUP INITIAL_TOOL=0 REFERENCED_TOOLS=!referenced_tools! TOOL_COLORS=!colors! TOOL_TEMPS=!temperatures! TOOL_MATERIALS=!materials! FILAMENT_NAMES=!filament_names! PURGE_VOLUMES=!purge_volumes! from slicer values.

Klipper has no idea what to do with them otherwise and barfs

[addoyle]

Sure, and that makes sense, but I'd expect that to cause a print to fail, not crash the entire system on start-up.

[ningpj]

Sorry, should have dug deeper. it appears you are getting a canbus timeout connecting to your mmu mcu. Other permission errors with network share as noted in other github issue.

• HH 2.73, mmu mcu canbus (canbus_uuid = 9807a00d48bb)
• Klipper version on mcu mmu is quite old (v0.11.0-180-g011b4e3 Vs v0.12.0-118-g18de421c on EBBCan) - IMO likely unrelated since you managed to start a print. I would update it though as a precaution
• Print started ...
• Printer restarted and now getting CAN connection error mcu 'mmu': Timeout on connect

I'm thinking its likely hardware related and would check your CAN bus cable and that you can still see both devices on your CAN network and work back from there....termination, etc. I cant see anything else obvious in the logs at the moment.

HH also has its own log - mmu.log

[github-actions]

This issue is stale because it has been open for over 30 days with no activity. It will be closed in 14 days automatically unless there is activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.