[BUG] MMU enabled causes CR10 display to stop updating/responding during prints

[Grntrenchman]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I have an Ender 3 Pro using an SKR 2 with 5x tmc2209, pi connected on serial 3 (wifi), MMU2S connected on serial 1 (tft), and stock display (CR10) on EXP1.

When printing starts (after homing, and idling to heat), the screen stops updating, showing the last thing (usually "E Heating") until the print is stopped or finished. I can spin the encoder, and the input goes through after the screen starts responding again.

I've used commands to check flow rate, spin encoder, check again, stop print, check again. the rate didn't change until the print was stopped.

I was directed to build without MMU, and that fixed the issue, so at least there's a starting point.

Bug Timeline

New

Expected behavior

I expected the screen to show current info about the print

Actual behavior

The screen freezes with info from first minute of print.

Steps to Reproduce

1. Enable mmu, cr10 display, uart serial
2. print something via serial
3. screen freezes

Version of Marlin Firmware

2.1.x bugfix

Printer model

Ender 3 Pro

Electronics

SKR 2

Add-ons

PI 4, IR filament sensor, MMU2S, dual Z drivers, bltouch

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

OctoPrint

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Marlin.zip -- MMU Disabled Marlin.zip -- MMU Enabled

I'm in discord most of the time, let me know if more/specific info will help.

[thinkyhead]

If you disable some other things but leave MMU2 enabled, does the issue still appear? i.e., The MMU2S could be interacting with another feature, not just in isolation.

You can try doing a build with MMU2_DEBUG to get extra logging to the host console, and see whether a lot of serial traffic is being created by the MMU2.

You can also try commenting out this line in MarlinCore.cpp to isolate the fact that it is the MMU loop causing the trouble…

  TERN_(HAS_PRUSA_MMU2, mmu2.mmu_loop());

If that fixes the issue, then (after restoring mmu_loop) you might try selectively commenting out parts of MMU2::mmu_loop in mmu2.cpp and see if any of that makes a difference.

[thinkyhead]

It may also be worthwhile to triple-check our pins and timers and make sure that there is no overlap between the serial port pins and other things with this particular board.

[Grntrenchman]

I'll be trying these selective commenting options now.

For more narrowing, the screen doesn't freeze if I start a print without interacting with the MMU. Boot -> Print = ok Boot -> MMU load to nozzle -> Print = no

It seems to happen at the first G1 or G92 call of the print.

Edit: More testing, it happens when the printer is "busy". If I "pause" the print at host, the screen comes back as soon as the last planned move stops.

[thinkyhead]

I'll have to check and see if the MMU2 serial is interacting with something like the MultiSerial by @X-Ryl669. As far as I know that serial port is isolated from the rest, but maybe it's getting messages intended for broadcast to hosts and serial LCDs.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.