Prusa-Firmware-Buddy
Prusa-Firmware-Buddy copied to clipboard
prusa3d
[BUG] Missing outer perimeter.
Is the perimeter in the gcode? If not then this is a slicer issue rather than a firmware problem.
I will note that you have not given any of the information requested by the issue report form. Perhaps you are venting rather than reporting an issue that can be fixed by Prusa...
I'm having this same issue on PrusaSlicer 2.7.1. Weirdly enough it's not happening in every spot on a single layer, just on some faces. Repeating every 7 layers or so when printing a Benchy.
I have the same issue, it happens random , on different models, different settings, once i saw it happening with my eyes, printer just skipped a few moves of perimeter and then continued printing as normal , After that i put the same gcode on print, and issue did not happen,
I contacted prusa , the guy told me there maybe be a faulthy wifi connection or usb drive, but gave me no solution for this
It looks like the printer just skips a few gcode lines and forgets about it
slicer is good because the same gcode worked the second time, maybe its because i use prusa connect?
im gonna try another usb drive, maybe the original one is too slow or something?
I have experienced similar problems. Since I disabled "Use ramping lift" in PrusaSlicer, I no longer have any problems.
I see you had the exact issue i have, but i dont even have "use ramping lift" enabled
For me the issue resolved after switching from Arachne to Classic generator in Slicer.
Had the same issue today twice. Different models, different printers. I have two MK4 printers and printed a model on the first one and saw a missing outer perimeter about 10mm above the bottom. The perimeter is missing in the whole layer- Later I printed something else on the other MK4 and had the same issue, but not on the same height, on the second print it was maybe 12mm above the bottom. It don't happen always. Printed some other things today and they were fine. I updated to 2.7.2 yesterday and haven't seen the issue before, so I thought 2.7.2 is maybe causing it. Then found this bug here, so I don't think it is related to 2.7.2.
@SmithyAT , provide some info about your settings, are you uploading directly on usb drive, or use wireless? Prusa link or Prusa Connect?
I am using Prusa Connect. Do you think it is related? I always thought that there should be no difference, because the gcode is stored on the use drive anyway.
@SmithyAT yes, because i use Prusa Connect too, but some times i used usb drive, and issue never showed, i think there is a probability, we should switch to usb drive and see if this issue ever shows up, because i used the same gcode , and first time issue persist and second time no, i think its like the prusa skips some gcode steps while downloading it over wifi, Do you use upload, or upload and print ?
@SmithyAT , provide some info about your settings, are you uploading directly on usb drive, or use wireless? Prusa link or Prusa Connect?
I am using default settings in prusa slicer, the model is quite simple, a block with a few cut-outs on the top (it is a holder for some things in the bathroom). But I've seen your suggestion to turn off ramping lift, and checked my settings, it was enabled, seems to be on per default. Will try to disable it with the next print.
Do you use upload, or upload and print ? Both, but as far as I can remember I clicked "upload and print"
But good hint, will try to copy it manually to the usb drive. WIth the wifi speed and the general transfer, everthing could happen :-) Maybe there is no check if the checksum is correct after the transfer.
But as already said in my initial posting, I've never seen the problem before and I never copied the gcode manually, I am always using PrusaConnect. But it is worth to try it, thanks!
@SmithyAT i had these issue pretty often , but on very random time, i was using "upload and print" button, but now for a few months i click "upload" and then wait for the file to full upload, and then i click "print" on the printer, and that way issue never showed up, but im just really venting about this nonsense bug , im sorry xd
I can understand that, it's annoying. Will take care next time, how I send the job and will give it a try to just upload it. Hope it will be fixed soon, these workarounds needed for PrusaConnect are really annoying, its not the first one, since I used it.
I have same issue on my mk4, firmware 6.0.0, Prusa slicer 2.7.4. I am using prusa connect.
I have the same issue with my Mk4 and mini, when using wifi there is a random missing/extra line in the prints.
I cant find any difference in the gcode between wifi and usb transfered files. It only affects 50% of prints and at different places with the same gcode.
Here is some more examples. Tried lots of different things with Prusa Support over a couple of weeks,
Also the usual:
- perimeter first
- archaine,
- other filament
- other USB
- other STL,
- tested ascii and binary G-code,
- new nozzle and cold pulls
The only thing that worked was stop using wifi. Seams to mostly be a problem when using PETG though. I think its only one error per print, often at 10-15mm height. Printing the same GCODE several times gives some good prints and some bad.
I never experience this, but because I always send the file via PrusaConnect and then I print from the LCD panel. This can be related to the WiFi BUG that afflicts the MK4 since it was born (see: [BUG] Prusa Connect / Link Gcode Corruption on OTA gcode upload #3156
Do the following:
- Configure in PrusaSlicer a physical MK4 printer with PrusaConnect.
- Slice the model in PrusaSlicer and export on your PC.
- Then upload the same code to the printer using the G button.
- Wait for the complete transfer.
- Go on the LCD and exit from the ready to print screen and back to the main menu.
- Remove the USB key and connect it to the PC
- Binary Compare the two files if are the same.
here is a quick and dirty way:
- go in windows command line with Start and select Command Prompt
C:\Users\john>fc /b PCobjectName.bgcode D:\MK4objectName.bgcode
Comparing files PCobjectName.bgcode and D:\MK4objectName.bgcode
**FC: no differences encountered**
If you get the "FC: no differences encountered" then the file was not currupted during PrusaConnect transnsfer. 8. Reinstall the USB dongle on the MK4
-
Go on the LCD panel, select the object that you have checked and print it.
-
I suppose that 100% of time it will be perfect. No way to fail.
-
Then go in PrusaConnect, and you should be able to see the same object also there.
-
Print it from PrusaConnect
-
I am not sure if PrusaConnect is just printing the local USB copy or is resending the whole file.
-
If it is using the local copy the it should be 100% correct.
-
If you get a bad print with a line, then may be it resent the gcode. In this case after the print, remove the USB. connect it to the PC, and reissue the FC command from dos command. Then the bgcode file should be different.
Let us know.
Regards
@antimix I experienced issues with my new Mk4 as well. In particular, at a certain height (on one specific part on one print only) it moved veeeeeeeeeery slowly (barely noticeable). But it recovered after I paused the print (which took forever as well, probably 5 minutes or more). Unfortunately I did not follow your guideline because I only researched the issue after it happened.
The printer has the latest 6.0.4 firmware.
This is what I know:
-
The file was transfered to the Mk4 via PrusaConnect from PrusaSlicer 2.8.0 and started directly. The issue occured at a height of 16.65mm on a move without extrusion and continued during the next movements with extrusion.
-
It seems to have recovered after pausing the print, but the pause took very long to be in effect.
-
After the print finished (well, it failed, because the part came off the bed. Not sure if that's related or not.), I downloaded the .bgcode file and it is 100% identical with a file that was saved locally.
-
Then I disabled PrusaConnect and PrusaLink (I did not use PrusaLink, it was just enabled) and restarted the same file and it did not have the same issue. However the printer was powercycled in between.
-
Previously I had issues with incomplete outer perimeters as well, which seems to be gone now too.
-
The issue has been present in two different WiFi networks in two different parts of Germany with different internet connection speeds (50MBit and 16MBit). Both routers are Fritz!Box routers, however different types.
I had this issue the other day on one of my first prints from Prusa Connect to my MK4. The printer simply skipped some of the gcode on the top layer, leaving a sort of diagonal stripe of missing material. I sent the print directly from Prusa Slicer 2.8.0 to my MK4 which is running 6.0.4+14924.
I downloaded the gcode from the printer and exported it from the slicer. Comparing the two files using the diff utility on the Mac, they are identical. And of course if I look at the gcode file with the gcode viewer utility in PrusaSlicer, it does not show any part missing.
Phooey. Happened again, this time on my XL. Apologies for the quality of the photo. I snapped the pic while it was still printing and it was ASA so the enclosure was closed. This was on my XL 5T running 6.1.2.
I have the same problem (Firmware 6.1.2+7894) and the frequency has increased in the last few weeks. I now have this issue in almost every print, in the beginning it only occurred quite rarely. I transfer the files via Prusa Connect and usually start the print from the display.
I had this issue the other day on one of my first prints from Prusa Connect to my MK4. The printer simply skipped some of the gcode on the top layer, leaving a sort of diagonal stripe of missing material. I sent the print directly from Prusa Slicer 2.8.0 to my MK4 which is running 6.0.4+14924.
I downloaded the gcode from the printer and exported it from the slicer. Comparing the two files using the diff utility on the Mac, they are identical. And of course if I look at the gcode file with the gcode viewer utility in PrusaSlicer, it does not show any part missing.
I have had this happen also, a couple of times. Did the same comparison test and found that g-code was identical.
Ugh.
Me too. I also had the XL USB drive disconnected issue. Wonder if it's related.
Read this post here about noise: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3983#issuecomment-2349212153
I'm not sure how the Mk4 cables are routed but the XL is right along with the z motor wires and closer to the main board, also with the Y.
I sent all of it off to prusa for analysis.
I also had one support on the red print fall over - not sure why - but it's like that one layer just didn't fully print and it fell over.
These are two different iterations on two different versions of firmware (XL 6.1.2 and 6.2.0 alpha) and the red one is also sliced with the newest prusa slicer released two days ago, where the black was the previous version. I transferred the file directly to the USB from my computer. I have prusalink and connect disabled on my XL, though - wifi is still enabled.
@WeaselWasher
These are two different iterations on two different versions of firmware (XL 6.1.2 and 6.2.0 alpha) and the red one is also sliced with the newest prusa slicer released two days ago, where the black was the previous version.
I don't understand what you meant by this.
Also, yes, guys, if you are having skipped gcode issues like what I see on the photos from @michael-kobb, please try out 6.2.0, should be fixed there: https://github.com/prusa3d/Prusa-Firmware-Buddy/releases
@CZDanol
By different iterations, I mean that it was the same model, repeated.
The black print was done in 6.1.2 and the red was done 6.2.
So, you had a USB disconnected issue on 6.2.0?
I had no fault, but I did have the missing perimeter (this is a thread for missing perimeters) is this the same problem as the USB disconnected issue?
I have a different petg print going right now that's been going for 12h so far, in two colours. But I haven't noticed any issues yet. It's only half done though. I won't be able to fully inspect it until it's done, but so far no USB disconnect faults or visible missing perimeters
@CZDanol
Yes. It appears I am still getting the missing perimeters in today's print with 6.2
It's a little hard to see - as it's translucent. But you can definitely see the blob