Lost communication with MCU error on _MMU_ACTION_CHANGED.

[Saikedo]

I am having an issue where very often when swapping filament, klipper will crash saying

Error running _MMU_ACTION_CHANGED: Lost communication with MCU 'mmu'

I even tried commenting out everything in that macro but the error still occurs. Here is my log file from MMU in case if that is helpful. There are 2 crasehs logged here, one of them is at the very end of the file.

mmu.log

Any idea what is going wrong here?

[ningpj]

Could you also please attach your mmu config (zip up the base directory) and klipper log

[Saikedo]

Here is my mmu config folder.

I also at some point got another error when loading a filament. Have not seen this error before. I got this/
Error running _MMU_ERROR_DIALOG: MCU 'mmu' shutdown: Move queue overflow

mmuZipped.zip

[ningpj]

Can you also please attach the klipper & moonraker logs as well.

When it failed and lost communication was it just printing or were you doing something else like uploading a new gcode file from your slicer?

Also want to confirm you are running ERCF v2 RC1 as your config reads like a 1.1 upgrade with springy and other mods. Likely doesn't make any difference just want to confirm.

From your discord chat I think you are also running this with a Fysetc ERB?

[ningpj]

I can see a stepper timeout in your log preceding the first comms failure so pointing to a potential wiring/driver issue with your gear/extruder stepper and will need to have a look at your klipper.log.

09:09:52 Did not complete homing move: Timeout on wait for 'tmcuart_response' response

[Saikedo]

klippy (3).log
@ningpj I lost track of which klippy log was attached to the above log so hopefully this will show what you need.

Quick question, I added this into my config since I saw orcaSlicer recommended it. Any idea if this can be the source of the issues that I am seeing? I am doing some tests now to see if removing this fixes the issues.

[gcode_arcs]
resolution: 0.1

[ningpj]

wouldnt have thought so. arcs is pretty standard stuff and have this set on all my printers. Im thinking this is a CAN bus issue between your mcu and toolhead board (ercf is over usb) since it mostly prints fine when its not loosing connection :-). Technically appears to happening while homing the filament on load so could be a symptom of the klipper homing bug (moggieuk may have some insights). Check cpu loads on your Pi as well....if you have a web cam and/or nozzle cam, disable themwhile you work on this issue or at the very least, drop their resolutions and framerates.

Unable to obtain tmc extruder phase Did not complete homing move: Timeout on wait for 'tmcuart_response' response

What model of toolhead CAN board are you using and how is it connected to your main mcu? - via utoc CAN/USB board or direct to octopus or orther CAN port? Also what speed is your CAN bus running at? 1,000,000?

Can you also please attach your CAN network stats (provided your Pi hasnt been rebooted since the last failure)

ip -d -s link show can0

[Saikedo]

I did restart the printer so can`t get the logs :(

So I am not sure what exactly changed but this is what I have so far. It started working after these things.

I was adding some logs in mmu.py to see if I can pinpoint the issue.
I removed the [gcode_arcs].

I have been printing for about an hour now with no klipper crasehs. Will try to investigate things a bit more but either gcode_arcs with 0.1 resolution was causing overload on the pi or adding console logs in mmu.py somehow fixed something for me.

I did had an experience with this before where adding console.log introduced a bit of a delay in a system and ended up magically fixing some issues. No idea, will try to debug some more.

As for toolhead can, I am using EBB BT36 I believe via Can directly attached to the BTT Octopus Pro. It is running at 1,000,000.

[ningpj]

Dump your can networks stats and keep an eye out for errors and dropped packets....some are fine and byproduct of restarting mcu's etc. lots however....

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1024
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 1000000 sample-point 0.750 
	  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
	  gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
	  clock 48000000 
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          22         115        0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped missed  mcast   
    3262115    505177   0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    808684     115857   0       0       0       0    ```

[moggieuk]

Any updates on this? There isn't a lot I can do. A lost communication is pretty fundamental and it does seem to be occurring more with the latest (possibly more with 64-bit) rpi OS.

Check cables are good quality and try adding ferrite rings around comms cables.