Filament not loading correctly with Prusa MMU Plug-in

As I'm not seeing this Issue raised on the GitHub repository for Prusa MMU, I thought I would post this in here to a wider audience.

What is the problem?

When I start a print from a file stored on the Raspberry Pi, with the plug-in Prusa MMU enabled, the nozzle and bed begin heating to the set temps (215/60). Once those temperatures have been reached, the Prusa MMU plugin pops up a dialogue box asking which filament to use.

Once I select the required filament, the printer immediately goes into homing and bed levelling (BL) without loading any filament. When the BL is complete, the printhead rises up and moves to the front right in order to do a filament reload/change. However, there is no filament loaded and when I press the printer button to confirm filament has been removed, the printer asks which filament to load. It then loads the selected filament and the print carries on as normal.

Previously, the Prusa MMU plug-in would bring up the dialogue asking for a filament shortly after starting the print, before the set temperatures had even been reached, and the filament would load as normal once the set temperatures were achieved.

Did you try Safe Mode?


Did Safe Mode solve the problem?


What did you already try to solve it?

Since the issue has only starting happening recently (within the last month or so, hard to tell as I don't run my printers every day), I checked back to see what changes I had made, and the only 2 plug-ins that were updated recently were the Prusa MMU plug-in itself, and the Slicer Thumbnails plug-in.

I disabled the Slicer Thumbnails plug-in - this initially seemed to solve the issue. However, the problem returned after another Octoprint restart.

I manually checked the operation of the 2 filament sensors and they both triggered correctly, and they both show 0 when the homing and BL starts. I also checked that there was nothing obstructing the sensors.

I rolled the Prusa MMU plug-in back to the 2023-10-1, the 2023-9-16 and the 2023-2-26 versions in turn, and the problem still remained. It had previously worked fine with the earlier versions, but I don't think it ever worked with the latest, current version.

I then disabled the Prusa MMU plug-in, and the printer worked correctly.

Additional information about your setup

  • Prusa Mk3S+ (FW 3.13.0) plus MMU2S (FW 3.0.0)
  • OctoPi 1.0.0cam (build 2023.05.23.124648) on Raspberry Pi 3B+
  • Octoprint 1.9.3 (same problem with 1.9.2)
  • Python 3.9.2

Plugins installed

  • Cancel Objects (0.4.7) (disabled)

  • Dashboard (1.19.10)

  • DisplayLayerProgress Plugin (1.28.0)

  • OctoPod Plugin (0.3.15)

  • PrintTimeGenius Plugin (2.3.1)

  • Prusa MMU (2023.10.7)

  • Slicer Thumbnails (1.0.3)

  • SpoolManager Plugin (1.8.0)

  • UI Customizer (

  • WebcamTab (0.3.1)

  • Windows 11 Pro 22H2 OS Build 22621.2428

Systeminfo Bundle (196.9 KB)

Sample G-Code file

2_x_pin_sculpfun_0.2mm_Esun PLA - Silver_42m.gcode (1.2 MB)

I've removed the thumbnail codes blocks.

Thank you advance for any help.

I've done some more investigating, using the latest OctoPi image with Octoprint 1.9.3 and with Prusa MMU being the only plug-in installed (other than the default Octoprint ones) - and the fault is still there. It appears that it causes the printer (or Octoprint) to ignore the Tx command in the Start G-Code. Disabling the plug-in solves the issue.

I'll now raise the issue on the plug-in's repository.

I appear to have solved the issue.

For some reason, with this Start G-Code for the printer, the problem occurs (note the location of the Tx command):

M73 P0 R41
M73 Q0 S41
M862.3 P "MK3SMMU2S" ; printer model check
M862.1 P0.4 ; nozzle diameter check
M115 U3.8.1 ; tell printer latest fw version
G90 ; use absolute coordinates
M92 E284.264
M83 ; extruder relative mode
M104 S215 ; set extruder temp
M140 S60 ; set bed temp
M190 S60 ; wait for bed temp
M109 S215 ; wait for extruder temp
G28 W ; home all without mesh bed level
G80 ; mesh bed leveling

However, if I move the Tx command to occur between the M140 and the M190 commands, the issue disappears. I have no idea how the Tx command ended up after the M109, as I've just looked back over some earlier g-code files, and the Tx command is before the M190 command. I certainly didn't move it there.

Sorry to have bothered you all

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.