Extremely Slow Printing and Gaps in the Layers  

RE:

I also have been having this issue! I've been scouring this forum to see what is going on with my factory assembled MK4.

I've seen it do the same thing, it will slow to a crawl, (like 0.5mm/s) while printing, or it will randomly travel off of the print before returning to it. I tried flashing back to stock firmware, but the same GCODE files still have the same issue, I tried reslicing and that somewhat worked, but randomly it is still having these issues. I heard some people mention that bad USB drives might be the culprit; so I need to try swapping mine out, but I already had gotten rid of the stock USB for a pretty high end samsung usb drive.
Something is so wrong with my MK4, I can't trust it to finish a long or complicated print. 

The other thing I'm seeeing is that the same GCODE file will fail or do the same thing strange behavior during the same part of the print, however if I reslice and use the same exact settings and even see that the SHA-1 hashcode between the two gcode files is exactly the same; the failing gcode on the USB drive will fail exactly the same way, while a renamed and copied GCODE file will run just fine. It is incredibly weird, but I need a printer that actually works, and I'm wondering what I'm going to do when my MK4 kits come in... can I really sell my reliable MK3S printers? I don't think I can unless these MK4 issues are resolved.

RE: Extremely Slow Printing and Gaps in the Layers

Like you literally threw away the USB drive that came with the printer so you can’t try that one? Just because a drive is name brand doesn’t mean it can’t have issues.

If you sliced your files with the input shaper printer profile, you need to reslice them with the normal profile to print with the non-input shaper firmware.

Also be sure to factory reset after flashing non-IS firmware. May or may not be necessary, but was one of the things that solved an issue on my Mini, which uses the same microcontroller and similar firmware.

Posted by: @cbutters

I also have been having this issue! I've been scouring this forum to see what is going on with my factory assembled MK4.

I've seen it do the same thing, it will slow to a crawl, (like 0.5mm/s) while printing, or it will randomly travel off of the print before returning to it. I tried flashing back to stock firmware, but the same GCODE files still have the same issue, I tried reslicing and that somewhat worked, but randomly it is still having these issues. I heard some people mention that bad USB drives might be the culprit; so I need to try swapping mine out, but I already had gotten rid of the stock USB for a pretty high end samsung usb drive.
Something is so wrong with my MK4, I can't trust it to finish a long or complicated print. 

The other thing I'm seeeing is that the same GCODE file will fail or do the same thing strange behavior during the same part of the print, however if I reslice and use the same exact settings and even see that the SHA-1 hashcode between the two gcode files is exactly the same; the failing gcode on the USB drive will fail exactly the same way, while a renamed and copied GCODE file will run just fine. It is incredibly weird, but I need a printer that actually works, and I'm wondering what I'm going to do when my MK4 kits come in... can I really sell my reliable MK3S printers? I don't think I can unless these MK4 issues are resolved.

RE: Extremely Slow Printing and Gaps in the Layers

Posted by: @jseyfert3

Like you literally threw away the USB drive that came with the printer so you can’t try that one? Just because a drive is name brand doesn’t mean it can’t have issues.

If you sliced your files with the input shaper printer profile, you need to reslice them with the normal profile to print with the non-input shaper firmware.

Also be sure to factory reset after flashing non-IS firmware. May or may not be necessary, but was one of the things that solved an issue on my Mini, which uses the same microcontroller and similar firmware.

Posted by: @cbutters

I also have been having this issue! I've been scouring this forum to see what is going on with my factory assembled MK4.

I've seen it do the same thing, it will slow to a crawl, (like 0.5mm/s) while printing, or it will randomly travel off of the print before returning to it. I tried flashing back to stock firmware, but the same GCODE files still have the same issue, I tried reslicing and that somewhat worked, but randomly it is still having these issues. I heard some people mention that bad USB drives might be the culprit; so I need to try swapping mine out, but I already had gotten rid of the stock USB for a pretty high end samsung usb drive.
Something is so wrong with my MK4, I can't trust it to finish a long or complicated print. 

The other thing I'm seeeing is that the same GCODE file will fail or do the same thing strange behavior during the same part of the print, however if I reslice and use the same exact settings and even see that the SHA-1 hashcode between the two gcode files is exactly the same; the failing gcode on the USB drive will fail exactly the same way, while a renamed and copied GCODE file will run just fine. It is incredibly weird, but I need a printer that actually works, and I'm wondering what I'm going to do when my MK4 kits come in... can I really sell my reliable MK3S printers? I don't think I can unless these MK4 issues are resolved.

 

I didn't throw it away, I carry a lot of thumb drives for various purposes to lots of different areas too and from work and I haven't been able to locate it at the location where I am currently at. Also I am not entirely certain it is the thumb drive or not, it is a wild guess at this point based on hours of trial and error and a few other posts I've seen with people guessing the same thing.

 I realize that you can't use an input shaper sliced gcode file on the original firmware, that isn't part of my issue.

Do you know if you can still use a regular profile MK4 sliced gcode even when using the alpha firmware? I assumed you could, but that is an aside.
My testing was with a regular sliced gcode file and I had the same issue with that gcode file whether on input shaper firmware or regular firmware.
Slicing it a second time, renaming it, and even comparing the SHA1 values show that it is the exact same GCODE as before, yet copying it to the printer with a different name works, while the original gcode file in place will malfunction on the print in the same spot. Here is a video of how the printer behaves when malfunctioning:

RE:

Posted by: @cbutters

I also have been having this issue! I've been scouring this forum to see what is going on with my factory assembled MK4.

I've seen it do the same thing, it will slow to a crawl, (like 0.5mm/s) while printing, or it will randomly travel off of the print before returning to it. I tried flashing back to stock firmware, but the same GCODE files still have the same issue, I tried reslicing and that somewhat worked, but randomly it is still having these issues. I heard some people mention that bad USB drives might be the culprit; so I need to try swapping mine out, but I already had gotten rid of the stock USB for a pretty high end samsung usb drive.
Something is so wrong with my MK4, I can't trust it to finish a long or complicated print. 

The other thing I'm seeeing is that the same GCODE file will fail or do the same thing strange behavior during the same part of the print, however if I reslice and use the same exact settings and even see that the SHA-1 hashcode between the two gcode files is exactly the same; the failing gcode on the USB drive will fail exactly the same way, while a renamed and copied GCODE file will run just fine. It is incredibly weird, but I need a printer that actually works, and I'm wondering what I'm going to do when my MK4 kits come in... can I really sell my reliable MK3S printers? I don't think I can unless these MK4 issues are resolved.

You are describing exactly the same behavior I am observing. Sometimes just re-slicing the same input with the same settings fixes the problem and sometimes not. I've had 12 hour prints on Speed mode with input shaper produce flawless results, then thoroughly poop the bed on the next print. I've also had several prints where the Z-axis suddenly drops by like 2-3 cm and crashes into the print, ruining it and knocking it off the print bed. Re-slicing the same input also seems to fixes that problem, but in both cases the behavior is too random to pin down a cause-effect relationship. It is clear, however, that it makes no difference if I slice it with or without input shaping in Prusa Slicer (though I have not tried downgrading the firmware yet).

I am using a brand new USB drive, but that is because the one that came with it failed completely. I copied files to it on my PC and ejected it, but when I inserted it into the printer (with the shipping firmware, not the alpha) it said there was no USB device. Since then it is no longer visible as a storage volume (and I've tried two different OSes on three different computers)—it is completely bricked.

Now I am wondering if there is a bug somewhere that is corrupting USB drives/volumes? I'm also curious if you copy files over the network or if you copy them to the USB drive from the computer and then plug that into the printer. I have been copying them over the network and just leaving the USB drive inserted because I was worried about bricking another USB drive.

I am going to look in to streaming gcode over USB (e.g., with Octoprint, like I've done for years with my MK3). I will also compare MD5 sums before/after inserting the USB drive and report back here if I find anything.

RE:

Yes, I also am using a 3rd party drive and copying gcode over the network via Ethernet (PrusaLink) (Could be a correlation to these issues possibly?).

This morning I'm trying a different USB Stick (I went back to a 8GB USB 2.0 drive to keep it as simple as possible) to see if I can get prints to complete. I'll keep you and this tread posted on what I find.

RE:

I'm also curious if you copy files over the network or if you copy them to the USB drive from the computer and then plug that into the printer. I have been copying them over the network and just leaving the USB drive inserted because I was worried about bricking another USB drive.

There are reports on GitHub of file corruption when uploading via Prusa Link or Prusa Connect - https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3156 and https://github.com/prusa3d/Prusa-Link/issues/820 .

The way in which the file is corrupted is very recognizable. Small portions of the source file are copied to random locations of the destination file, resulting in corrupt gcode and unexpected printer behavior.

To find out if this is your problem, after slicing, use the "Export G-code" button to save a local copy, and also upload to the printer via the network. If the print fails, plug the USB drive into your computer and compare the local copy to the file on the usb drive. If you don't have a good way of comparing the files, post them somewhere and I or someone else can take a look.

Note that this problem hasn't happened to me, but the issue on GitHub caught my eye when I was looking for something else.

RE: Extremely Slow Printing and Gaps in the Layers

The way in which the file is corrupted is very recognizable. Small portions of the source file are copied to random locations of the destination file, resulting in corrupt gcode and unexpected printer behavior.

Thanks for pointing that out; it sounds like exactly what is happening when, for example, the extruder moves to random locations during a print.

I just exported the same gcode, once to disk and once over the network and then checked the MD5 sums of the file I wrote to disk locally versus the one copied to the USB over the network and they are different!

RE:

Posted by: @dark-helmet

The way in which the file is corrupted is very recognizable. Small portions of the source file are copied to random locations of the destination file, resulting in corrupt gcode and unexpected printer behavior.

Thanks for pointing that out; it sounds like exactly what is happening when, for example, the extruder moves to random locations during a print.

I just exported the same gcode, once to disk and once over the network and then checked the MD5 sums of the file I wrote to disk locally versus the one copied to the USB over the network and they are different!

I'm seeing the same thing! Thanks for the info @jvasileff I'm now printing reliably by not copying things over with PrusaLink and my prints are no longer failing. Sounds like they really need to get that sorted out quickly, I've lost hours and hours and a lot of filament over this pretty standard use case. I see this link also shows progress on the issue: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3156

RE: Extremely Slow Printing and Gaps in the Layers

I thought you had checked the SHA-1 hash? Or did you not check the hash of the gcode on the USB drive itself, but the one you threw into PrusaLink to transfer?

Posted by: @cbutters

 

Posted by: @dark-helmet

The way in which the file is corrupted is very recognizable. Small portions of the source file are copied to random locations of the destination file, resulting in corrupt gcode and unexpected printer behavior.

Thanks for pointing that out; it sounds like exactly what is happening when, for example, the extruder moves to random locations during a print.

I just exported the same gcode, once to disk and once over the network and then checked the MD5 sums of the file I wrote to disk locally versus the one copied to the USB over the network and they are different!

I'm seeing the same thing! Thanks for the info @jvasileff I'm now printing reliably by not copying things over with PrusaLink and my prints are no longer failing. Sounds like they really need to get that sorted out quickly, I've lost hours and hours and a lot of filament over this pretty standard use case. I see this link also shows progress on the issue: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3156

RE:

Posted by: @jseyfert3

I thought you had checked the SHA-1 hash? Or did you not check the hash of the gcode on the USB drive itself, but the one you threw into PrusaLink to transfer?

Posted by: @cbutters

 

Posted by: @dark-helmet

The way in which the file is corrupted is very recognizable. Small portions of the source file are copied to random locations of the destination file, resulting in corrupt gcode and unexpected printer behavior.

Thanks for pointing that out; it sounds like exactly what is happening when, for example, the extruder moves to random locations during a print.

I just exported the same gcode, once to disk and once over the network and then checked the MD5 sums of the file I wrote to disk locally versus the one copied to the USB over the network and they are different!

I'm seeing the same thing! Thanks for the info @jvasileff I'm now printing reliably by not copying things over with PrusaLink and my prints are no longer failing. Sounds like they really need to get that sorted out quickly, I've lost hours and hours and a lot of filament over this pretty standard use case. I see this link also shows progress on the issue: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3156

 

Yep, that's exactly right.

First I got the SHA-1 on the PC of the the first gcode (which was failing on the printer)

and then I got the SHA-1 on the PC of the 2nd gcode file that was the same model just renamed (which was not failing on the printer) 

They both matched on the PC and I didn't think to check the SHA-1 directly on the printer's USB (didn't realize that the act of sending a file over PrusaLink was the culprit) at the time I made that post.

Either way looks like this isn't related to Input Shaper at all; and its nice to have a working printer again (sans Prusalink)

Extremely Slow Printing and Gaps in the Layers [SOLVED]

Copying gcode to the USB stick locally and then plugging it into the printer has solved the problem for me. My prints are all coming out perfectly now, in any print mode.

Below I try to summarize the issue, since my guess is that other users are affected, but haven't been able to pin down the cause because the bug occurs randomly and the symptoms are hard to diagnose until you discover the bug.

For anyone who runs into a similar problem in the future:

The issue is that the MK4 randomly swaps the byte offsets of 32 byte chunks of some gcode files that are sent to it over PrusaLink when writing them to the USB volume. The result is prints that have completely random gcode commands sprinkled throughout an otherwise mostly-intact print.

The bug has a github issue from which is sounds like the problem is on the printer side. It does not appear to be related to the input shaper, the alpha firmware, the OS or software used to generate the gcode or whether it is transferred over Ethernet, WiFi, LAN or PrusaConnect. It occurs at random and the symptoms are prints that fail due to weird and unexpected movements of the print head. For me, it manifested as the print head moving very, very slowly; the print head randomly moving the end of the X-axis and back (as though it were doing a phantom filament change); and the print head suddenly dropping a few cm on the Z-axis, knocking prints off the bed.

RE: Extremely Slow Printing and Gaps in the Layers

Interesting thread. I've had a few of the same issues as described here since updating to the RC firmware. I've spent the past day or so going in circles trying to get back to a working printer.

Watching this thread with interest and trying the local USB solution in the meantime.

RE:

Just to add, I've got another symptom (amongst a few issues, see here and here) where the printer randomly reboots when printing something I've sent direct from PrusaSlicer via PrusaConnect to the printer. It seems I've now got a Gcode file that forces the issue every time. Is it worth me adding the GCode to the github issue?

I've not yet tried this print by copying direct to the USB.

(Edited to add): I saw some other odd behaviour last week, where mid-print the printer would think it needed a filament change, even though there was no change in the Gcode from the slicer. Wonder if this is another manifestation of the issue?

RE: Extremely Slow Printing and Gaps in the Layers

Wonder if this is another manifestation of the issue?

Any unexpected printer behavior could be a symptom. The key is to check if the gcode file on the USB drive differs from the original file (which you would have to independently save from Prusa Slicer to your computer.)

Is it worth me adding the GCode to the github issue?

If you have both the original (good) and usb (corrupted) files, I would think yes. Either way, I'm sure it would be helpful to share your experience on the github issue, including firmware versions used and other details when the errors occurred, since that is the info the devs are currently asking about. Just be clear about whether you suspect corruption or if you've actually confirmed it by comparing the files.

RE: Extremely Slow Printing and Gaps in the Layers

I went away for a few days so just coming back to this. Did some preliminary testing last night with a GCode file that causes my machine to freeze consistently on each print. Discovered something slightly worrying/interesting: even if I slice the file direct out of PrusaSlicer to USB on my PC and then try to print, I get the same resetting issue as mentioned in this thread.

So, I did a bit more testing of SHA1 for various versions of the file:

• "Export G-code" button saved to local PC hard drive - > copied to USB drive
• "Export G-code" button saved to local PC hard drive - > uploaded via PrusaLink via browser
• "Export to SD Card / Flash Drive" button saved direct to USB drive
• "Send to printer" button via PrusaLink
• "Send to printer" button via PrusaConnect

I gave the file a different name each time but otherwise changed nothing. The SHA1 was identical for each version of the file, and each one caused the machine to stop dead in the middle of a print and reset. PrusaConnect shows "UNKNOWN" as status for each of the prints.

I'm about to role back to firmware 5.0 alpha to see if the files still fail, then 4.7.2 out of curiosity.

RE: Extremely Slow Printing and Gaps in the Layers

(Couldn't edit the last post)

I've just opened new bug #3219 on github for my issue as it feels slightly different.

RE: Extremely Slow Printing and Gaps in the Layers

Rolling back to firmware 5.0 alpha has just allowed me to successfully print one of the problem G-code files.

RE: Extremely Slow Printing and Gaps in the Layers

Quick update - TL;DR: I'm an idiot but also seem to have fixed the issues I was experiencing similar to 3156 and 3219 by performing a hard factory reset and firmware upgrade back to the latest RC. This included an update to the WiFi module.

Has anyone else tried this and experienced the WiFi update?