[BUG] [MMU] Wrong Z height after failed filament load.

[NotJannet]

Printer type - MK3S+
Printer firmware version - 3.13.2

MMU upgrade - MMU3
MMU upgrade firmware version - 3.0.1

SD card or USB/Octoprint - SD card

Describe the bug
I have experiencing a lot of failed filament loads during prints this past week.
This issue has happened 4 times now.
I come back into the room to find the printer waiting for input from the user as filament loading has failed.
Most frequently this is because the filament has fallen out of the back of the MMU3 during the print.
I press the button, it resumes printing temperature, re-homes the MMU3 and then I feed the filament in so it can load.
It then returns to the wrong Z height, lower than expected, burying itself into the purge block & causing the print to fail.
On one occasion the failed loading happened in the first couple of layers, resulting in the nozzle ruining the PEI on a steel sheet.

To Reproduce
This error has been intermittent as there have also been failed filament loads that I've corrected and the print has continued without issue.
However, the exact steps would be:
Begin multi-colour print (mine was using 4 colours, this may be irrelevant).
Remove one filament from the MMU during print so it cannot load.
Wait for the printer to try and load this filament & fail.
All the times this has happened, the nozzle has fully cooled. Unsure if relevant.
Press "retry", wait for temperature & for the MMU to re-home.
Feed filament into the MMU when it tries to load the filament.
Upon successful load, wait to see if it returns to the correct height.

Expected behaviour
Whenever the hot end is moved out of position during an error state, I expect the nozzle to return to the same height & position it was before being moved.

[gudnimg]

I'm unable to reproduce this. @NotJannet does this happen above some certain Z height? How often does this happen? Does it not happen everytime?

Test 1: Don't allow the nozzle to go cold, retry immediately

Output on Parking:

• MMU code saved resume position (mm):
  • X: 184.323
  • Y: 135.500
  • Z: 0.200
• G-code M114 output: X:184.32 Y:135.50 Z:0.20 E:-12.78 Count X: 183.17 Y:136.64 Z:0.32 E:-12.78

Output on Unparking:

• MMU code saved resume position (mm):
  • X: 184.323
  • Y: 135.500
  • Z: 0.200
• G-code M114 output: X:184.32 Y:135.50 Z:0.20 E:12.98 Count X: 183.17 Y:136.64 Z:0.32 E:12.98

---

Test 2: Allow the nozzle to cool down to 170°C

Output on Parking:

• MMU code saved resume position (mm):
  • X: 184.323
  • Y: 135.500
  • Z: 0.200
• G-code M114 output: X:184.32 Y:135.50 Z:0.20 E:-12.78 Count X: 183.17 Y:136.64 Z:0.30 E:-12.78

Output on Unparking:

• MMU code saved resume position (mm):
  • X: 184.323
  • Y: 135.500
  • Z: 0.200
• G-code M114 output: X:184.32 Y:135.50 Z:0.20 E:17.30 Count X: 183.17 Y:136.64 Z:0.30 E:17.30

---

Test 3: Allow the nozzle to cool down to under 50°C (same print as in Test 2, I just allowed the next layer to continue)

Output on Parking:
MMU code saved resume position (mm) - X: 215.677, Y: 128.090, Z: 0.400

• MMU code saved resume position (mm):
  • X: 215.677
  • Y: 128.090
  • Z: 0.400
• G-code M114 output: X:215.68 Y:128.09 Z:0.40 E:-11.19 Count X: 214.51 Y:129.19 Z:0.45 E:-11.19

Output on Unparking:

• MMU code saved resume position (mm):
  • X: 215.677
  • Y: 128.090
  • Z: 0.400
• G-code M114 output: X:215.68 Y:128.09 Z:0.40 E:23.24 Count X: 214.51 Y:129.19 Z:0.45 E:23.24.

[gudnimg]

One possible way your issue could happen is move_raise_z(MMU_ERR_Z_PAUSE_LIFT); doesn't lift the Z all the way (it should lift up exactly 20mm). We've seen a similar issue with the underlying code in XYZ Calibration.

[NotJannet]

@gudnimg Thank you for doing the above testing. I cannot currently reproduce the issue myself as I've been encountering other issues with my printer relating to loading.

To answer your questions

• All 4 times this has happened, it's been at different heights, the lowest was at 0.3 (using a 0.1 layer height).
• Since posting, the filament failed to load (although this was due to an issue in the hot end instead of filament failing to load into the mmu) and continued successfully after intervention. It is difficult to say if it happens every time as I cannot presently reproduce.
• This has happened 4 times over the past week, although it is difficult to say how many other prints I've done in that time.

[gudnimg]

@NotJannet Next time you see the issue, it would be interesting to know how high up is the nozzle relative to the highest point of the print so far. For example if there is no difference, then that would explain a lot.

[bazzadark]

The issue has been occurring for me as well and I previously posted up in the Prusa forum. attached is a jpg of what looks like a layer skip I had today on a 2 colour MMU print. I wasn't watching the printer at the time so I am hypothesising that there was a loading problem which was automatically recovered by the printer but skipped the layer. (In the pic the light brown had the load fail, skipped the layer, perhaps tried to print the next light brown layer, changed tool head to the dark brown which printed Ok and continued on.)
The problem occurred at layer 7.00mm (0.2mm layer height). I intend to check the G code but I may just reprint to see if the fault duplicates

Earlier occurrences of the issue were observed with load fails that required my manual intervention with similar layer skip on only 1 colour of the MMU print.

hope this is of assistance.

{my environment}
Printer type - MK3S
Printer firmware version - 3.13.2

MMU upgrade - MMU3
MMU upgrade firmware version - 3.0.1

SD card or USB/Octoprint - Octoprint

[Laloe1630]

I have the same issue. I have an original MMU3 with a fystec MK3S+ clone. I didn't have this issue with the MMU2S.

[Laloe1630]

I found the problem with my printer which was doing the same thing.

I replaced the SD card with a new one. I'm using a Verbatim 16gb SD card with 80mb/s read speeds.

My MMU3 is working fine now. I have done 2 mmu prints so far.

[3d-gussner]

@Laloe1630 Thanks for the feedback, so your issue has been solved by using a new SD card?
You can print more MMU prints now without any issues.

[Laloe1630]

@Laloe1630 Thanks for the feedback, so your issue has been solved by using a new SD card? You can print more MMU prints now without any issues.

Yes, a new SD card solved the issue for me.

I'm currently 10 hours into an 80 hour mmu print.

[ih57452]

I believe I've encountered either this same bug or something very similar, only I don't have an MMU. I'm printing from Prusa Connect and don't have an SD card in the printer, so that can't be the issue. It first happened when I had a small part detach from the bed and caused a crash detection on the X axis. It re-homed and then immediately tried to start printing again. It went back to the spot where it crashed and then jammed the nozzle into the build plate (I didn't see that happen the first time), then it re-homed again and then I saw it jam the nozzle into the build plate a second time. I know it happened twice because there are two nozzle marks on my two week old satin sheet. I stopped the print after that and thought it must have been something related to the crash detection, so I turned crash detection off and started a different print that had a pause for a manual color change. It printed the first color for 8 hours just fine, but after it paused and I got the filament changed out, it jammed the nozzle into the corner of the part and ruined the print. I've gone from having a printer that hasn't had an issue since 2018 to one that I can't trust not to tear itself apart in the course of two days.

Printer type - MK3
Printer firmware version - 3.13.2

MMU upgrade - none

SD card or USB/Octoprint - PrusaLink 0.7.2 Pi Zero 2 W

[Laloe1630]

The problem came back a few prints after replacing the SD card. I also tried replacing the power supply. The last thing I changed to fix the problem was the board.

[Prusa-Support]

Please notice that this problem may be confused with an "empty layer" where something went wrong with the filament loading and part of the layer was printed at the correct height but without extruding plastic. It may be the case for some of the reports in the thread judging by the pictures.

However, I may speculate this may be related to a rare bug we have recently reproduced and worked on - not sure.
Does the error persist if you downgrade to firmware 3.13.1(+3.0.0) / 3.13.0(+3.0.0)?

Michele Moramarco
Prusa Research

[Prusa-Support]

This issue may be related to issue #4476.
As suggested at #4571 (comment), please give the new firmware release 3.13.3 a try and let us know if the problem is fixed for you.

Michele Moramarco
Prusa Research

[3d-gussner]

Closing due to lack of interaction

[bazzadark]

Couldn't further comment on this issue as I have moved to Mk3.5 but had no layer issue since 3.13.3 which I used for a couple of weeks prior to 5.2.1 upgrade.
thanks
Barry

[3d-gussner]

@bazzadark Thanks for the update and confirming that with 3.13.3 your issue has been solved. Enjoy your 3.5

[bazzadark]

I am seeing the issue (missing colour in a layer) on my Mk3.5/MMU3 config on most long prints (20 hr/500 tool changes) and was wondering if this fix was implemented into the Buddy board environment. I would like to rule this out as I think it is a different issue in the 3.5 config with MMU grinding filament at the end of a load sequence causing the lack of extrusion on a colour in a layer. ( I will raise a separate issue on this observation shortly )

Firmware is Mk35_6_0_1 & MMU3_3_0_3
Using REVO Hotend and Octoprint 1.10.1

thanks
Barry

[Prusa-Support]

There is only little in common between 8-bit firmware based on RAMBo boards and the 32-bit firmware based on Buddy boards so please, go through the existing issues on the Buddy-specific repository, where MK3.5 issues should be listed too.
https://github.com/prusa3d/Prusa-Firmware-Buddy/

However, based on the picture and your previous comments, we can't exclude a partial clog that led to a skipped portion of layer, which is probably a whole different sporadical problem.
With a reminder that this issue was potentially related to low motion accuracy [ -> fixed ] and not necessarily to the filament loading, you may want to document and review future happenings with our Customer Support.

Michele Moramarco
Prusa Research