[BUG] Lcd unresponsive during print with MMU2 on SKR PRO V1.1

[darkspawn91]

Bug Description

Reprap_discount_smart_controller unresponsive during print if I use the MMU2 on SKR Pro.

My Configurations

Marlin.zip

Steps to Reproduce

1. Wiring MMU2 to TFT port on SKR PRO

2. #define SERIAL_PORT -1
   //#define SERIAL_PORT_2 1
   //#define SERIAL_PORT_2 internalSerial
   #define MMU2_SERIAL Serial1

Everything work but if I define Serial_port_2 MMU2 not respond to LCD commands.

3. MMU2 is connected and responsive with lcd commands but when I print the LCD is unresponsive during print and return ok when finish.

4. If I never active MMU2 commands from LCD, everything work fine, also with MMU2 connected.

Expected behavior:

LCD usable

Actual behavior:

LCD unresponsive

[nbenzaki]

I am having the same issue with the stock display.
skr v1.3
no issues with the standard build for an ender 3 and tmc2130
also no issues with a cyclops setup (2 extruders)

after compiling the firmware for an MMU2 I have a few extruder related issues + the display will not respond to anything during the print.

[TB1405]

same problem here with SKR Pro. But while filament change during a print the lcd works.

[darkspawn91]

Yep. It works during filament change and also, for me, during very long perimeters.

[Minims]

I have the same issue too. LCD unresponsive while printing. Change. filament is OK. (SKR PRO)

[darkspawn91]

I have noticed one thing. When you not use MMU2 load/unload commands on LCD everything works. So, the problem is the communication from LCD to MMU2 unit.

[boelle]

@darkspawn91 so not an issue with marlin as such?

[Minims]

If you use the MMU menu before printing it freeze while printing.
If you don't use this menu, it works. I agree with that.

I think the problem is on Marlin side. It's like the LCD is waiting for MMU serial instead of the board serial And/Or it can be a timing problem with serial communication.
I don't know how to help on this issue.

For information I have had the same issue with a 8 bits board : GT2560.

[darkspawn91]

@boelle I think the problem is in marlin. Something like communication.

[darkspawn91]

@Minims I followed your issue. I can confirm there is a bug on SKR Pro using MMU2. Serial_Port2 just to be undefined or MMU2 not have interaction with LCD. Just few days ago LinoBarreca had fixed Tx/Rx assignment on SKR Pro, I had tried to define Serial_Port2 1, MMU2 on TFT port, but nothing change.

[Minims]

@darkspawn91 mmu2 is on uart port on my side : serial3. I Try on Tft port too. There is always a freeze on lcd.

[darkspawn91]

Which Serial you use on Configuration.adv? I have
#define MMU2_SERIAL Serial1

[Minims]

I use this setup :

#define SERIAL_PORT 1
#define SERIAL_PORT_2 -1
...
//#define INTERNAL_SERIAL_PORT 2
#define MMU2_SERIAL Serial3

[darkspawn91]

@Minims So, can you use the two serials ports, maybe for a TFT screen?

[Minims]

@darkspawn91 yes, I have TFT + ESP3D ,USB, MMU2 and LCD 12864. All working together.

[Minims]

New try with last bugfix version. Same Issue.

MMU : Load Filament.
MMU - ENABLED
MMU <= L0
MMU => 'ok'

Load file from SD CARD on LCD 12864.
G28, G34, G29 executed from file.
LCD is still UP.
Then going in front to make the priming line and LCD freeze

[Minims]

New test, I have take the only 50 first line of my gcode, make a new code with this and it works.
The code stop before printing but after priming because only first 50 lines, but no freeze. With the complete code it freeze just before priming. don't know what it means.
Memory problem when code is quite big ?

[darkspawn91]

@Minims or something like buffer? Because I have tried with big gcode and LCD works only during slow perimeters.

[Minims]

@darkspawn91 buffer is a good idea !
I have a really big improvement while tuning this.
I have still some small "lags" on the LCD, but it's better.

Here is my values, it might need some tuning. Tell me if it help.

@@ -1654,16 +1654,16 @@
 // The number of linear motions that can be in the plan at any give time.
 // THE BLOCK_BUFFER_SIZE NEEDS TO BE A POWER OF 2 (e.g. 8, 16, 32) because shifts and ors are used to do the ring-buffering.
 #if ENABLED(SDSUPPORT)
-  #define BLOCK_BUFFER_SIZE 16 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
+  #define BLOCK_BUFFER_SIZE 32 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
 #else
-  #define BLOCK_BUFFER_SIZE 16 // maximize block buffer
+  #define BLOCK_BUFFER_SIZE 32 // maximize block buffer
 #endif
 
 // @section serial
 
 // The ASCII buffer for serial input
 #define MAX_CMD_SIZE 96
-#define BUFSIZE 4
+#define BUFSIZE 32
 
 // Transmission to Host Buffer Size
 // To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
@@ -1672,7 +1672,7 @@
 // For debug-echo: 128 bytes for the optimal speed.
 // Other output doesn't need to be that speedy.
 // :[0, 2, 4, 8, 16, 32, 64, 128, 256]
-#define TX_BUFFER_SIZE 0
+#define TX_BUFFER_SIZE 32
 
 // Host Receive Buffer Size
 // Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.

[boelle]

a lot of updates and fixing has happend in the last week, is the problem still there?

[Minims]

Problem still exist by default on my skr pro, but once BUFFER is tune as said on my last comment, it works.
Don't know if it an stil issue or a comment to set in Marlin to precise this.
Waiting for feedback from other mmu2 users

[boelle]

so its just a config that needs to be changed for it to work?

[Minims]

Yes, maybe @darkspawn91 can confirm it fix his issue too.

[darkspawn91]

Sorry @Minims, I’m not at home now. I’ll try this weekend. I’m really happy you improve with this change. I hope it will work also for me. I’ll tell you soon.

[boelle]

@darkspawn91 we are waiting in excitement :-)

[burst80]

I have the same problem. SKR 1.3, MMU connected to the TFT port. I changed the buffers, but the problem still occurs.
Port configuration:
#define SERIAL_PORT -1
//#define SERIAL_PORT_2 1
#define MMU2_SERIAL Serial1

[BastR]

@Minims I tried the values but the problem is still there :(, maybe it appears less often but it's still there

[BastR]

I did some tests this morning.

On Prusaslicer I have 2 profiles for the same printer, 1 profile in classic mode acting like a mono-extruder printer and 1 in multicolor mode.

Classic mode

Test 1:

• I remove the current filament with the MMU2 menu.
• I load the new filament in the nozzle with the MMU2 menu.
• I launch the print
• At the end of the last G29 measurement point, the LCD freezes.

Test 2:

• I use the filament already present in the nozzle.
• I launch the print
• No LCD problem

Multicolor mode:

Test 1 (same behavior as Test 1 classic):

• I remove the current filament with the MMU2 menu.
• I load the new filament in the nozzle with the MMU2 menu.
• I'm launching the print
• At the end of the last G29 measurement point, the LCD freezes.

Test 2:

• I'm making sure there's no filament in the nozzle.
• I launch the print
• G29 OK.
• The MMU2 loads the filament into the nozzle.
• LCD is OK

[darkspawn91]

@BastR same things. The LCD freeze when you have a direct interaction with MMU2 using load/unload from LCD. No Slicer problem. I also used other slicer but with same results. I’m a noob so I don’t know what is the problem, but I have Raspberry Pi4 with 7” touch connected and it works perfectly, so maybe the problem is the LCD buffer or something else. The MMU2 board also not have total connection with SKR board, so maybe the interaction from LCD with MMU2 disconnect connection from LCD with board, because I noticed also that LCD works also during long perimeters or during filament change.

[darkspawn91]

@burst80 I have SKR 1.3 also and same problems on there.

[darkspawn91]

#15646
I found this merged. Does anyone know if there is a connection from this merged and our problems?

[BastR]

#15646
I found this merged. Does anyone know if there is a connection from this merged and our problems?

I don't think there's a connection, I already tried to force the TX/RX size but the problem is still there, just like that:

#if SERIAL_USB
   #define MMU_RX_SIZE 256
   #define MMU_TX_SIZE 256
 #else
   #define MMU_RX_SIZE 256
   #define MMU_TX_SIZE 256

[darkspawn91]

But we don’t have SERIAL_USB connection but UART connection, did I say wrong?

[burst80]

I have updated to marlin 2.0.5, the problem persists and is even worse. After using the MMU menu, the printer loses communication with the SD card. I have to remove and reinsert the card to print. This could be an SPI speed problem, in 2.0.3 I had the SPI quarter clock mode set.
Because my MMU is my own design, based on arduino nano, I decided to check communication with another device. I created a simple application that emulates MMU on the com port (USB adapter -> RS232 TTL connected to TFT on SKR) of the computer. Here the problem repeats. If someone is useful, I attach a link to the emulator:
https://drive.google.com/open?id=13nZoScbXGHfZFDNpqhG1jKCNO9IR4jZE
I suppose the problem is SD card support on the RepRapDiscount Smart Controller display. Earlier I used RAMPS + RE-ARM board based on LPC1768, there was also a problem with the sd card. Only the connector built into the board worked properly. I will try to check if after switching to the built-in SD connector the board will improve.

I did several tests, checked the operation with a built-in card reader, several buffer configurations and the effect is the same all the time. Using the MMU menu causes the display to freeze, it does not matter whether the printout is made from the sd card or serial port. I have tested the action in menu_mmu2.cpp from the original MMU.LOAD_TO_NOZZLE to the one used with GCODE T0, mmu.tool_change, without improvement. The only thing that works is using the custom menu. You must enable #define ADVANCED_PAUSE_FEATURE and #define FILAMENT_LOAD_UNLOAD_GCODES in Configuration_adv.h
Below are my custom menu settings:

#define CUSTOM_USER_MENUS
#if ENABLED (CUSTOM_USER_MENUS)
#define CUSTOM_USER_MENU_TITLE "MMU2"
#define USER_SCRIPT_DONE "M117 User Script Done"
#define USER_SCRIPT_AUDIBLE_FEEDBACK
// # define USER_SCRIPT_RETURN // Return to status screen after a script
#define USER_DESC_1 "MMU UNLOAD"
#define USER_GCODE_1 "M702"
#define USER_DESC_2 "LOAD FILAMENT 1" /
#define USER_GCODE_2 "M701 T0" // "M140 S"
#define USER_DESC_3 "LOAD FILAMENT 2"
#define USER_GCODE_3 "M701 T1"
#define USER_DESC_4 "LOAD FILAMENT 3"
#define USER_GCODE_4 "M701 T2"
#define USER_DESC_5 "LOAD FILAMENT 4"
#define USER_GCODE_5 "M701 T3"
#define USER_DESC_6 "LOAD FILAMENT 5"
#define USER_GCODE_6 "M701 T4"
#endif

It is not an elegant solution but it works, it allows you to load the selected filament into the nozzle, and unload it. The load filament and eject filament options are missing.

[burst80]

I don't know why it works, but it works.
When calling the function from the mmu2.cpp library as gcode, everything works fine and the lcd does not freeze. I added 4 gcodes M703-M706, and converted mmu2_menu to send gcod. Everything works on the default buffer settings.
Attached are all files that need to be replaced:
Marlin_mmu2_patch.zip
Files from Marlin 2.0.3
\Marlin\src\gcode\feature\pause\M701-m702.cpp
\Marlin\src\gcode\gcode.cpp
\Marlin\src\gcode\gcode.h
\Marlin\src\lcd\menu\menu_mmu2.cpp

Additionally, MMU2 support is possible from the level of gcode (sd card, serial port).
M703 T(extruder 0-5) - Load filament (M703 T1)
M704 T(extruder 0-5) - Load filament to nozzle
M705 - Unload current filament
M706 T(extruder 0-5) - Eject filament

[darkspawn91]

Wow @burst80 , very good job! I’ll try it later. So I think now that the problem is on MMU2 sub menu. If every MMU2 action works using G-code, someone can change it on mmu.cpp file. I’m attending that someone also implement dual filament sensor for MMU2S filament length. 😁
Do you think is it possible to do?

[darkspawn91]

Sorry @burst80 , can custom g-code M703-M706 be used during print to do something like a manual SpoolJoin like Prusa does?

[burst80]

Additional commands work like any gcod and can be used at any time. Change of the filament during printing should be done by Marlin himself. Since version 2.0.3, Marlin does not respond to changing the filament sensor in the MMU.

[boelle]

@darkspawn91
Please test the bugfix-2.0.x branch to see where it stands.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[github-actions]

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.