[BFW-5717] [BUG] MK4 prints out of object

[kifflavmraka]

Printer model

MK4

Firmware version

5.1.3, 6.0.3, 6.0.4, 6.1.2, 6.1.3

Upgrades and modifications

None

Printing from...

USB Drive

Describe the bug

I have 4 MK4s. At some point, all of them started to misbehave in a really weird way - mid-print they go outside the object, print in the air, then come back and continue printing where they're supposed to be printing. This results in failed print (or at least very bad quality, if you don't care at all about how print looks and you have the time to scrape all the excess material).

Video 1 - 0:05, 0:57
Video 2 - 0:08, 0:15, 0:55
Video 3 - 0:43
Picture 1 - Task failed successfully
Picture 2 - Failing in progress
Picture 3 - Failing in progress
Bonus Picture Issue reproduced over only 1 of the elements

What it's NOT:

• ❌ A single printer issue: it's reproduced on all 4 machines i have
• ❌ A single FW version issue: reproduced on multiple FW versions
• ❌ Extrusion problem: Filament is dry (enough), speeds are the default ones in MK4IS profile
• ❌ Layer shift: Belts are tensioned OK. The printer knows exactly where everything is, moves away, does strange stuff, then goes back to the object and continues
• ❌ Corrupted gcode: diff between gcode on usb stick and original on the computer shows no differences. Issue is reproduced in roughly 50% of the prints, the other half turns out OK
• ❌ Corrupted USB stick: 4 machines - 2 Prusa sticks, 2 SanDisks - reproduced at random on all of them
• ❌ PrusaConnect / internet connectivity issue: First I've stopped using PrusaConnect to transfer files, then I've disabled it completely, then I've removed the wifi cards from the printers - to no effect. My last MK4 has never been connected to internet, wifi never installed. Reproduced on it as well.
• ❌ Caching, if there is such thing on the printer: As the movements outside of the object somehow resemble the shape of the printed object, my thought was its some kind of caching of the gcode gone wrong.
  • Complete factory reset did not help.
  • Formatting the usb sticks before print, wrote a script to automate formatting and copying the gcode - no noticeable improvement.
  • Renaming the gcode files with a random hash at the end, so that every time printer prints a uniquely named gcode file - no noticeable improvement.

What it COULD be:
❓ Incorrect gcode interpretation: Although inspecting gcode doesn't show any incorrect movements, the printers do them anyway. Eventually I've started to test slicing with various gcode flavours in PrusaSlicer, which might give someone some clue about whats going on, because this changes the behaviour of the machines.
Gcode of the default flavour, Marlin 2 & RepRap/Sprinter reproduce the error at random moment of the print, usually in the beginning, but at no specific layer.
Gcode of Marlin (legacy) flavour, however, reproduce the issue more rarely and always at layer 1, thus making it easier to monitor and cancel & restart the print.
Picture 4 - Marlin legacy 1st layer reproduction
Picture 5 - Marlin legacy 1st layer reproduction
I'm currently testing behaviour with reprap flavour, I'll update the ticket when I have enough observations.

I'm willing to help with debugging this every way I can. I've communicated the problem with support and over email.

How to reproduce

1. Slice a model on PrusaSlicer 2.7.4/2.8.0 on Windows or Mac
2. Copy gcode manually or via PrusaConnect to usb stick
3. Start a print
4. Observe printer while it fails to follow correctly gcode instructions

Expected behavior

Print the sliced model without doing movements not specified in gcode

Files

files.zip

[danopernis]

Wow, this looks horrible. Thank you for the detailed information, we will try reproducing it.

[CZDanol]

Based on the video, looks like BFW-5717 to me. If that's the case, we will hopefully have a solution ready soon.

I appreciate the analysis already done on your side - this is a very high quality issue report :)

Btw. BFW-5717 relates to an issue in the temporary gcode buffer in the RAM.

[kifflavmraka]

Still reproducible on 6.1.3