search

prusa3d / Prusa-Firmware-Buddy

Firmware for the Original Prusa MINI, Original Prusa MK4 and the Original Prusa XL 3D printers by Prusa Research.
Other
1.13k stars 218 forks source link

[BUG] MK4 skipped printing a part mid layer #3682

Open andrelind opened 8 months ago

andrelind commented 8 months ago

Please, before you create a new bug report, please make sure you searched in open and closed issues and couldn't find anything that matches.

Printer type - MK4

Printer firmware version - 5.1.2

Original or Custom firmware - Original

USB drive or USB/Octoprint USB flash drive

Describe the bug Mid layer the printer just stopped, jumped a bit and then continued further along Looking in slicer it should not do this and it created problems on the next layer Had to stop the print and when restarting it, it worked...

IMG_2278 IMG_2282

G-code Bottom_0.4n_0.2mm_PLA_MK4IS_2h52m.bgcode.zip

AdamMaras commented 8 months ago

I think I’m experiencing this problem too, or at least something very similar to it. Same environment—MK4, original firmware 5.1.2, printing from USB.

I’ve been printing single-perimeter test objects for tuning, and twice I’ve watched the printer travel directly from one position on the perimeter to another (not following the expected tool path) and continue printing from that point. The issue doesn’t happen consistently; re-printing the same .bgcode file a second time is successful.

I’ll continue trying to reproduce this to get more information.

AdamMaras commented 7 months ago

I just had another failure, very similar to the one in the original post—just without the extrusion between the apparent stop and restart points. I measured the gap between completed lines of solid infill to be 19.6mm, which means the printer skipped just shy of 100 G-code instructions.

@andrelind are you able to measure the gap on your part on the failure you posted?

andrelind commented 7 months ago

I tossed my part in the bin but it seems about right, it was about 100 lines of gcode that was skipped and roughly 2cm missing

andrelind commented 7 months ago

Just got another failure, this time on my other MK4 so I guess mechanical errors is out of the picture... IMG_2336

AdamMaras commented 7 months ago

I spent much of the weekend trying to intentionally induce a failure so I could start narrowing down the issue. I got it to fail once, doing a vase mode print designed to easily estimate the number of steps skipped.

image image

About 120 steps were skipped.

I haven't been able to reproduce the problem (despite printing that test model about a dozen more times).

andrelind commented 7 months ago

Happened again, this time on the top surface... This is getting frustrating

IMG_2346

AdamMaras commented 7 months ago

Had another failure tonight. Skipped about 170 steps.

B284862B-507D-46F3-AD8D-79BE5E457A99_1_102_o

I'm still no closer to identifying any more useful information.

DiederikvandenB commented 7 months ago

Also experienced this once.

andrelind commented 6 months ago

And here we go again! IMG_2391

Worst fu**ng printers I've ever owned, my old Anet A8 was more reliable than this sht Now I'm missing a deadline due to faulty prints, this is costing me money and filament!

bstansell commented 6 months ago

I've been experiencing this as well (MK4, 5.1.2 and 5.1.3). Randomly the printer just skips over a chunk of codes. At first I thought it was the USB drive, but a new one shows the same. Also thought it might be related to https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3156, but the gcode viewer on my laptop shows a perfect model (no corruption) after loading from the USB drive and just reprinting the same model (original gcode from the usb) produced a flawless print.

Right now I'm wondering if there's some sort of electrical interference or corruption in RAM that's causing the codes to go sideways when the printer loads the file from USB. With these "random" skips and the fact that not everyone is complaining (I have a MINI that seems fine running 5.1.2 and a friend with an MK4 that doesn't seem to experience this), it feels "environmental" - in that something about my build is provoking this behavior (goes back to the electrical interference idea).

IMG_0409

bstansell commented 6 months ago

Right now I'm wondering if there's some sort of electrical interference or corruption in RAM that's causing the codes to go sideways when the printer loads the file from USB.

I went and reworked the ribbon cable wiring (my zip ties were folding them into a U shape in the xBuddy box and some of the cable routing wasn't 100% like their assembly instructions) but now I just have to print a lot to see if it makes a difference. ☹️

Has anyone tried turning off binary gcode? Been wondering if the decompression operations needed there is somehow colliding with other features enabled in the firmware and triggering a bug at that layer. If I see another skipped chunk of a print (ie the wiring didn't change anything), I'll be turning it off as my next test. Not being able to reproduce the problem on-demand is painful.

andrelind commented 6 months ago

Have not tried to disable binary gcode, will give it a shot today Although I don't think there's anything wrong with the files themselves since reprinting the same file works :-/

The other day I saw the printer started doing a "circle" pattern in the air, roughly 5cm in diameter, then skipping roughly 100 instructions and continuing printing (with a gap...). My guess is something is buffering or maybe the USB fails to read (have replaced my drives but still the same result) or maybe some RAM corruption

andrelind commented 6 months ago

Nope, disabling binary gcode did not solve anything... Got big nice "skip" all the way around here 👎 IMG_2414

andrelind commented 6 months ago

Downgrading to 5.0.1 and not connecting them to Prusa Connect works! Upgraded one machine to 5.1.2 and it still seems to work, so just disable Prusa Connect since the issue seems to be connected to that somehow

bstansell commented 6 months ago

Downgrading to 5.0.1 and not connecting them to Prusa Connect works! Upgraded one machine to 5.1.2 and it still seems to work, so just disable Prusa Connect since the issue seems to be connected to that somehow

Very interesting! I certainly have Connect enabled, but don't really need it. I haven't noticed any issues since reworking the wiring on my end, but the failures were so infrequent, it's not proof of anything one way or the other. I guess, for now, I'll keep Connect enabled and wait for the inevitable skip so I can show it wasn't the wiring, then immediately turn off Connect!

Prusa-Support commented 6 months ago

Thank you all for your input. Our developers are investigating this but we couldn't reproduce the problem so far.

Please let us know if downgrading firmware or disabling the network connections actually works for some of you. However, we suspect a problem with data transfer on the side of the USB flash drive, external interference, or a generic wiring problem.

Please consider (1) testing multiple USB flash drives to see if the problem only occurs with some specific USB flash drives.

Also, (2) reseat all xLCD wires, including the PE cable, and (3) make sure the printer is correctly grounded as follows.

Michele Moramarco Prusa Research

rickpeters commented 6 months ago

I experienced the same symptoms. Only thing I would like to add is that it only happened on the first try when streaming bgcode using prusa connect. On reprinting (which happens from flash drive using the bgcode) it works fine. What is strange is that it happens after the total file was already transferred. Maybe this will help the debugging?

Barbasnoo commented 6 months ago

I experienced this issue as well. It started only after the update that allowed for bgcode streaming.

My conditions to reproduce (3 times so far);

Bgcode format in latest PrusaSlicer and MK4 stable firmware as of March 19th 2024.

Streamed to MK4 via PrusaConnect.

Occurs on top, flat surfaces only, and rapidly jumps from the missed step, over the wide gap, to the resumed step (no delay during the skip, no printing mid air).

IMPORTANT ISOLATION STEP Using the same bgcode that experienced the error, I can start the print again using the MK4 display interface, and the issue does NOT occur. Additionally the anomaly does NOT appear in PrusaSlicer either.

IMPORTANT ISOLATION STEP I benchmarked the included flash drive, and purchased a high speed replacement flash drive and benchmarked it too, and on the replacement drive I marked it at over 20x faster than the included flash drive on both read and write speeds. I formatted the new drive, inserted it in to the MK4 and streamed a new bgcode print, and the issue occurred again. I once again verified the anomaly was NOT present in PrusaSlicer, and once again printed the same bgcode again from the MK4 display interface, and the issue did NOT occur.

It only seems to occur when streaming the bgcode over PrusaConnect in my experience. Regardless of the flash drive used, even the high performance flash drive experienced the same error.

Here are some photos of 2 of the failures I experienced. imageimage

andrelind commented 5 months ago

I experienced this issue as well. It started only after the update that allowed for bgcode streaming.

You might be on to something here, updated my Mini+ the other day and yesterday I got the same thing happening on it! No fails on any of my MK4s for weeks now running 5.1.3, but I don't use Connect, just run around with the USB-stick...

andrelind commented 5 months ago

I've now done extensive testing on my 2 MK4s this weekend, around 80 different prints from Thursday to Sunday Went through all the steps the devs wanted me to do before hand, and have 2 brand new USB sticks

I have both of them connected to Prusa Connect running 5.1.3 FW

Same result happens both with .gcode and .bgcode, so don't seem like the binary version is to blame

gotkasets commented 5 months ago

Hi @Prusa-Support,

I have same issue. 4h print and several times printing stops and freezes for several seconds. Fans keep working. Freezing causes big nasty plastic melting spots. Also I had last print skip parts for some layers and walls are broken on that location.

Also xLCD freezes same time.

As I am in the middle of the print I do pictures later.

I kept prusaLink enabled but disabled Prusa Connect and let's see if second half of the print still freezes.

Firmware Version: 5.1.3+13503 Buddy Board: 37 Files are uploaded over PrusaLink on local network from Prusa Slicer. Authentication is over APIKey

UPDATE: Prusa Connect is disabled, but still stops printing and freezes. Will keep observing

johnkray commented 5 months ago

Chiming in here. I have 8 MK4s, 2 XLs, and 4 MK3s. I have experienced this issue with all MK4s and XLs, but not with the MK3s. The issue is very hard to recreate. When the issue occurs re-printing the parts on the same printer with the same gcode usually results in a successful print. This issue started for me after the introduction of the compressed bgcode. Not sure if it is related. I have attached several pictures to help document the issue. I was able to get successful prints for all of these by just re-printing the same bgcode file with no changes to the printer filament. I'm using the provided thumb drive for all the printers except 2 and I've experienced this issue at least once a week if not every day on all printers and all thumb drives. I exclusively transfer files to the printers via Prusa Connect.

IMG_7498 IMG_7502 IMG_7185 IMG_7186

bstansell commented 5 months ago

Very interesting! I certainly have Connect enabled, but don't really need it. I haven't noticed any issues since reworking the wiring on my end, but the failures were so infrequent, it's not proof of anything one way or the other. I guess, for now, I'll keep Connect enabled and wait for the inevitable skip so I can show it wasn't the wiring, then immediately turn off Connect!

Well, it's been a month since I posted the above and I believe all has been stable. I've been printing a lot of random things and Connect has been enabled the entire time. Certainly seems like reworking the wiring has fixed it for me. If it hadn't, I would have thought I'd have noticed by now... 🤷

johnkray commented 5 months ago

Just a quick update. I'm still experiencing this issue once or twice a week. There is no consistency between which of my 10 printers or flash drives it happens on. Since my last post, I've updated to Prusa Slicer 2.7.4 and Buddy Firmware 6.0 on my MK4s and 6.0 RC3 for my two XLs. Just had the issue again today. This has been ongoing for a long time across many versions of Prusa Slicer and Buddy Firmware. And to reiterate from my previous posts, I primarily start/send prints from Prusa Connect and I've had the issue on all my flash drives, some of them Prusa supplied and some of them third party.

andyshinn commented 5 months ago

I'm curious if what I am experiencing looks like this bug. I posted about it at https://forum.prusa3d.com/forum/original-prusa-xl-tool-changer-hardware-firmware-and-software-help/missing-infill/ but I watched it twice now in the last couple weeks similarly just seem to skip a ton of steps (which results in missing infill or wall). The second time I caught it and it started making the letter r and abruptly stopped and just started moving towards the wipe tower (without retracting it seems like since it just started dragging a bunch of the PETG).

johnkray commented 5 months ago

I'm curious if what I am experiencing looks like this bug. I posted about it at https://forum.prusa3d.com/forum/original-prusa-xl-tool-changer-hardware-firmware-and-software-help/missing-infill/ but I watched it twice now in the last couple weeks similarly just seem to skip a ton of steps (which results in missing infill or wall). The second time I caught it and it started making the letter r and abruptly stopped and just started moving towards the wipe tower (without retracting it seems like since it just started dragging a bunch of the PETG).

Yes, this looks like the same issue

hanezzzz00 commented 4 months ago

Not sure if this is the same issue but I am quite suspicious it can be. Since upgrade from MK3s clone to MK3.5 I am experiencing some completely random events of underextrusion (which are screwing my prints]. Occurence is approx. 1/10 of my prints. MK3S had never this issue. I was even considering some clogging issue and upgraded to Revo :-) Which was great decision but it didn't not solved this issue at all :) It happens completely random and I am not able to reproduce. Tried different materials and changing idler screw tension but no effect. I am streaming bgcode from Prusa Connect to the original Prusa USB.

I didn't noticed that this issue was reported also for MK3.5 so I wanted to notice that MK3.5 can be the same case. Firmware 6.0.0 but I noticed this issue since first firmware versions.

EDIT: Now I remember that I also once missed part of the top layer on a print in the past, and now I understand that it was just a slightly different symptom of the same problem. After reading this thread I think it describes exactly the problems I occasionally have. I will try to focus on Prusa Connect streaming. I will try to change to sending files from the slicer directly to Prusa Link in the printer. If you are interested, I will try to share update in few days of testing (as said, not easy to reproduce...).

image

andrelind commented 4 months ago

Yeah this is the same issue My mini has the same problems so seems like a FW thing

I’ve printed LOADS of things in the last months with no problems, but I’m putting the files on USB manually As soon as I use Connect file transfer they start to fail in 10-15% of my prints

hanezzzz00 commented 4 months ago

Yeah this is the same issue My mini has the same problems so seems like a FW thing

I’ve printed LOADS of things in the last months with no problems, but I’m putting the files on USB manually As soon as I use Connect file transfer they start to fail in 10-15% of my prints

Just quick update. Since I switched from uploading bgcodes from Prusa Connect to Prusa Link (directly to the printer) I have had no problems. It's only been a week, but I've already printed numerous jobs and I'm starting to suspect that there really is a problem with bgcode streaming from Prusa Connect. I will add another update in the next week or if any fail occurs.

EDIT 6/May 2024 (another week of use): Still no issue, printer works perfectly.

EDIT 18/May 2024): Still no problem, looks like the problem has really been solved. I will try to switch back to Prusa Connect, just for fun, if the problem occurs again.

miltieIV2 commented 4 months ago

Does PrusaSlicer use the CRC32 checksum feature of the .bgcode format? If so, does the firmware check this CRC32 checksum? If not, do we need a "check bgcode CRC32" in Settings -> Hardware -> G-code checks?

andyshinn commented 4 months ago

Just quick update. Since I switched from uploading bgcodes from Prusa Connect to Prusa Link (directly to the printer) I have had no problems. It's only been a week, but I've already printed numerous jobs and I'm starting to suspect that there really is a problem with bgcode streaming from Prusa Connect.

Would this mean the resulting bgcode file on the printer USB drive should be corrupt as well? I haven't tried printing again from the same file already on the printer. Has anyone tried this to confirm if it is the actual file that gets transferred to the printer?

miltieIV2 commented 4 months ago

Corruption could happen anywhere: PrusaSlicer to local disk local disk to PrusaConnect within PrusaConnect transmission from PrusaConnect to thumb drive on the thumb drive (bit rot) read from thumb drive

The most likely failure through all of these would be truncation. Showing these CRC32 values everywhere file directories are shown would help Re-checking the CRC32 everywhere a file detail is shown would help.

hanezzzz00 commented 4 months ago

Just quick update. Since I switched from uploading bgcodes from Prusa Connect to Prusa Link (directly to the printer) I have had no problems. It's only been a week, but I've already printed numerous jobs and I'm starting to suspect that there really is a problem with bgcode streaming from Prusa Connect.

Would this mean the resulting bgcode file on the printer USB drive should be corrupt as well? I haven't tried printing again from the same file already on the printer. Has anyone tried this to confirm if it is the actual file that gets transferred to the printer?

At this point I have no confirmation of corrupted bgcode. I just noticed that disabling Prusa Connect and printing directly from USB (or using Prusa Link, that is basically the same method) works fine. Same for reprints. It looks like problems with randomly stopping extrusions (strangely nothing else!) are somehow related to streaming from Prusa Connect. I now print via Prusa Link and have not had any problems since.

Prusa-Support commented 3 months ago

Random freezing has been observed and reported before on https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3664, and that may actually lead to inconsistent extrusion or partial clogs (= skipped portion of a layer). Thus, these issues may be potentially related.

This issue is hardly reproducible; therefore, we can only speculate so far. However, we may probably narrow down the tests to the following scenarios - again, the causes are still uncertain and hardly reproducible.

Of course, there may be much more to play a role so testing shouldn't necessarily be limited to these scenarios, and we keep collecting your valuable feedback in pretty much all of our support channels.

Michele Moramarco Prusa Research

BreakMate commented 3 months ago

I appreciate that Prusa support is responding to this thread and providing us with possible troubleshooting steps. That being said, I've been experiencing these issues months ago. After contacting prusa support with evidence and a video of the printer running and stopped, I was advisedto try and disable networking, even going as far as disconnecting the WiFi adapter. I can attest that the issue of missing portions of layers and skipped infill was fixed.

A couple of days ago, I was curious to see if the issue has been fixed, so I reinstalled the WiFi adapter and connected to WiFi (I was previously on Ethernet, just to rule out wireless issues). I'm sad to say that the issue has reared its ugly head once again. As you can see in the picture, part of the first layer is missing. This is not a physical problem with the printer, as I have not seen this issue until I reconnected the printer to Prusa Connect. I understand that this is hardly reproducible, but there must be some sort of checks in place to diagnose these types of issues.

Ill continue to monitor with a surveillance camera and try to catch it again in the act. Not sure how it might help, but Id like to have a time stamp to compare any other events that happened in that moment. 20240610_084255

pyrho commented 1 month ago

Printer: MK4 FW: 6.0.4 Prusa Slicer 2.8.0 Print started from PrusaSlicer through Prusa Connect.

1 (1) 2

headphoneholder(1)_0.4n_0.2mm_PLA_MK4IS_52m.bgcode.zip

I've been having this issue pretty randomly, maybe once every 15 prints, and I only use Prusa Connect.

I've read (in this thread I think) that this is an issue only when printing through Connect, I'll try only printing through Prusa Link and see if this issue still occurs.

\<rant> Prusa needs to get their sh*t together, this has been an issue for 7 months now... It pains me, but I'm having a hard time recommending Prusa printers nowadays... \</rant>

andyshinn commented 1 month ago

I know this comment is really just a "me too" but I want to keep adding to the fire since I really want it to get more visibility by Prusa.

I have stopped using Prusa Connect or PrusaLink and the issue went away. It doesn't seem to be USB related (at least for transferring files from computer to printer). I haven't tried only PrusaLink but would be curious to know if that exhibits the issue. I just don't want to have to deal with the issue anymore and it is hard to reproduce. So, the fix is to shuffle USB flash around 😩 which is frustrating.

Prusa Connect is a decent interface and I would like to keep using it. Even if only for getting files from my computer to the printer easily.

rickpeters commented 1 month ago

I still use prusa connect, but always use the queue even if I could directly print. So first wait for the full upload finishing and only then I will start the print from Prusa Connect. Until now it works successfully Hope other people will be helped by this also

andrelind commented 1 month ago

I stopped using Prusa Connect in February, I’ve only used PrusaLink since then and not a single failure due to this

I bet there is some way for the file to be corrupted when starting from Connect and it starts before the whole file is downloaded. PrusaLink is the same file, on the same USB drive, downloaded using same WiFi module but it does not start before it is all downloaded And it just works 🤷

03julian04 commented 1 month ago

Hello everyone I just want to update this... I also have the problem with my XL so exactly as it was described ... missing layer and it is not reproducible. I hope Prusa finally finds a solution ...

gotkasets commented 1 month ago

Hi @Prusa-Support !

I posted here long time ago! (If you search my last post look my username and post under that)

I think my problem was that I used bgcode from printables. Despite this bgcode were ment to my exact printer, it did stuck the print. This print were different from other because of multicolor settings! I changed colors by hand.

BUT NB! It did happened and stuck only on large mono color parts! Printing single color BOX wall!

I am now sliced all files myself and problem never happened again.

Not still 100% sure why it happened! and never again!

I regulary update also firmware and slicer as soon as I can! Soo I have now several latest firmwares forward now!

Best Regards, Gotkasets

n6ham commented 4 weeks ago

I just had a very unpleasant experience with the same issue that manifested itself in a much worse manner.

Firmware v: 6.0.4+14924 Slicer v: 2.8.0 Mac Ethernet connection Prusa Connect setup but not used

Then I sliced a longer print (8.5h) exported a non-binary gcode file to the stick supplied with the printer and started the print. Around 41% in, the printer paused for ~40 seconds, then raised the head considerably and continued printing in thin air. The progress jumped from 41% to 86% shortly. It took MK4 a bit more than hour to "complete" print, some 3.5 hours earlier than supposed to.

The Connect acted weirdly. Initially, the printer was shown as IDLE on Prusa Connect page. But when I decided to check it mid-print - it was shown as offline. I also couldn't open Prusa Link locally (via IP on my laptop, whilst I could open the same IP on my iPhone; all three devices (printer, laptop, iphone) were in the same VLAN, so I'm not sure what was it acting up)

The only other suspicion I have - there was something wrong with supplied USB stick. It came with some pre-sliced gcode files, including the one I printed first.

First thing I noticed - when I tried to eject the drive on my Macbook, after copying the new print gcode - it never ejected. Second thing - when I tried to check the drive after the failure using my Windows PC - the tool said that there were errors on the drive. I decided to re-format the drive and give it another try tomorrow (keeping fingers crossed).

I do have a video clip of this incident and a gcode file that was on the flash drive when it happened, just in case it may help with debugging.

andyshinn commented 4 weeks ago

That sounds a bit more dramatic than the issue in this thread. I think what we are generally talking about is a case where the printer skips a set of instructions (like 100-200 gcode lines) but continues to print without pause as if nothing happened. It manifests itself as unfinished layers or perimeters which leads to poor quality in the finished part. But usually not significant raising of the head or printing in complete air or long pauses.

n6ham commented 4 weeks ago

It looks just like a more severe case of the same kind of problem discussed previously. The only difference might be in the amount of skipped gcode

Btw, another attempt to print the same stuff (after a usb stick was formatted) just finished successfully.

Prusa-Support commented 3 weeks ago

It looks like most of the new reports actually match one of the cases listed in the message above https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3682#issuecomment-1998040694, especially overlapping operations like G-code streaming or USB drive problems. However, I agree that the last case seems to be a more severe case of corruption on the printer' side, probably to be addressed with a power cycle or even a hard reset.

The developers are doing everything they can to improve the firmware and avoid potential scenarios resulting in this issue. I wish I could bring positive news but due to the erratic nature of this behavior, there is still work to be done and the investigation continues.

Michele Moramarco Prusa Research