search

prusa3d / Prusa-Firmware

Firmware for Original Prusa i3 3D printer by PrusaResearch
GNU General Public License v3.0
2.01k stars 1.05k forks source link

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

Closed NotJannet closed 5 months ago

NotJannet commented 9 months ago

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 commented 9 months ago

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:

Output on Unparking:

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

Output on Parking:

Output on Unparking:

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

Output on Unparking:

gudnimg commented 9 months ago

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 commented 9 months ago

@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

gudnimg commented 9 months ago

@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 commented 9 months ago

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 IMG_1624

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 commented 8 months ago

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

Laloe1630 commented 8 months ago

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 commented 8 months ago

@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 commented 8 months ago

@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 commented 7 months ago

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 commented 7 months ago

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.

PXL_20240120_213304673

Prusa-Support commented 6 months ago

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 commented 6 months ago

This issue may be related to issue #4476. As suggested at https://github.com/prusa3d/Prusa-Firmware/issues/4571#issuecomment-1981150886, 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 commented 5 months ago

Closing due to lack of interaction

bazzadark commented 5 months ago

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 commented 5 months ago

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

bazzadark commented 3 months ago

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

bingo_layer_problem

thanks Barry

Prusa-Support commented 2 months ago

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