Printer stops mid print  

Page 1 / 2
  RSS
gautam.j
(@gautam-j)
New Member

My MK3S completely stops (in the middle of a print) quite frequently.  The print cannot be continued after this happens.  I'm using Slic3r PE 1.41.3+win64 and FW 3.7.0.

Until now, I assumed it was a random problem (maybe wiring, power, serial disconnect..).   However, after the most recent incident, I can now  reproduce the issue.  I still don't know why it happens.

When a stop happens:

  • the front display looks unchanged
  • the nozzle and heatbed remain heated
  • extruder does not move and it melts a 'hole' into the part at its current location.
  • OctoPrint keeps getting new messages `Recv: echo:busy: processing`
  • pressing pause from OctoPrint or the front panel (if printing from SD) has no effect
  • only way out is a reset

The last time it happened, it stopped 30 minutes into the print.  When I tried to print the file again, it stopped at the exact same point.

I've trimmed the gcode down, but I can't identify the exact line causing the problem.  Could anyone help test this on their printer?  (Please unload your filament and disable the filament sensor before testing.  I have a different nozzle, hot end, and extruder).


In the past, I had also tried the following.  However, I'm fairly certain now that these are not causing the problem:

  • Turning off the filament sensor
  • Stopped using the SD card (maybe it was corrupted).  I setup Octoprint using a new Sandisk SD.

Also, I did replace my original extruder with the Bondtech upgrade and a E3D Volcano.  This was partly because I wanted to print with higher flow rates, but also because the I kept getting 'thermal runaway' issues with the original extruder.  

 

Posted : 27/04/2019 9:41 pm
andy.b17
(@andy-b17)
Eminent Member

I've had a similar issue in the past and the way I resolved it was to format the SD card.

If it's just that one print that's an issue it could be the stl file...Try the formatting and also a different stl / gcode.

Hope that helps...

 

Posted : 30/04/2019 8:08 pm
Tim
(@tim-m30)
Illustrious Member

I'd eliminate Octoprint from possible causes by printing the suspect file from the built in SD card.  If it also fails there, then move on to the next diagnostic steps.

And turning off the filament sensor is the first thing I recommend when prints stop mid file.  If you haven't done so, try this again.

This post was modified 9 months ago by Tim
It is always wise to get more than one opinion......
Posted : 30/04/2019 9:23 pm
Ben Park
(@ben-p17)
Active Member

First, I'm almost positive we can rule out the Octoprint. The symptoms you see on Octoprint are lost comms from an Arduino processor. I recognize the message. Second, this is happening with my prints as well. I believed it to be the SD card, swapped it out and reprinted with the same failure. Now, I suspect the front panel system is losing comms with the RAMBO board. This would fit the signs, no visible failures, no failure stats, etc. But, that is just a guess on my part. I suspect the SD card reader in my case but it could be something else with the display card that is causing the issue. I am printing a 4th test print. If it fails, I am installing my backup display/SD. If I get a good print after swapping the display, I've narrowed it down and will re-post. If not, still guessing...

Ben Park
benpark@knights.ucf.edu...
Posted : 13/11/2019 10:42 pm
Tim
(@tim-m30)
Illustrious Member

@gautam-j - This sounds like a printer losing it's place due to interrupt mishandling.  Not exactly uncommon on the MK3, but stopping at the exact same place would be unusual.  Since the commands within the clipped code look normal, I wouldn't suspect the code.  Some other factor is probably in play. 

 

It is always wise to get more than one opinion......
Posted : 14/11/2019 4:58 am
Ben Park
(@ben-p17)
Active Member

gautam-j and I have the same or similar issues. I am posting my diagnostic steps here in hopes that together we can find the answer. 

After replacing the SD card itself with no change, I replaced the front panel LCD board thinking maybe the issue is with the SD reader itself, No change. I'm out of thoughts on the front end. 

Recap of steps taken:

  1. On notice of failure, reprinted (failed in almost the exact same spot - nozzle touching print, nearly centered on X, (Y not consistent)
  2. Tried this twice (reslice, reprint - still failed)
  3. Swapped SD card for another working one, printed different model (both sliced with prusaslicer from Fusion360 models)
  4. Tried this twice (resliced, reprint - still failed)
  5. Replaced front panel model (SD reader and LCD) - still failed print

Failures all have the nozzle touching the print near centered on X but not in exactly the same place in the model. Prints range in time from 3.5hrs to 12hrs. Printing in PETG.

Next steps until issue found:

  1. Test print a non-Fusion360 model just to make sure it is not something common to Fusion360.
  2. remove and re-connect all connections on RAMBO board - retest
  3. replace RAMBO board - retest

Anyone have any other steps or idea?

Ben Park
benpark@knights.ucf.edu...
Posted : 14/11/2019 11:15 am
Ben Park
(@ben-p17)
Active Member

Forgot to mention...

STL file has no recognized errors. I always fix models with NetFabb and resave. Prusaslicer shows no model issues. 

Ben Park
benpark@knights.ucf.edu...
Posted : 14/11/2019 11:20 am
Tim
(@tim-m30)
Illustrious Member

What does the printer say for reported crashes for the print, or is crash detection disabled?

 

It is always wise to get more than one opinion......
Posted : 14/11/2019 11:39 am
Ben Park
(@ben-p17)
Active Member

Crash detection is enabled. Zero crashes under the statistics screen and no on-screen indictions of a crash.

The best indicator I received was on the LCD itself. Percent complete dashes, time remaining = dashes 

Ben Park
benpark@knights.ucf.edu...
Posted : 14/11/2019 12:08 pm
Tim
(@tim-m30)
Illustrious Member

What are the X and Y belt tension numbers? 

ps: the dashes sounds like something in the firmware is pausing; but will require some digging.  Can you be a bit more specific in exactly what is being displayed in the timer fields?  [----%]  [===]h [===]m or whatever you see at a stall? 

This post was modified 2 months ago by Tim
It is always wise to get more than one opinion......
Posted : 14/11/2019 12:46 pm
Ben Park
(@ben-p17)
Active Member

I don't understand why the X & Y belt tensions matter (for this issue), can you explain? 

X=258

Y=295

The tension has been the same for a while now, printing great for quite a long time. 

I've updated a picture of the latest fail on the screen.

Ben Park
benpark@knights.ucf.edu...
Posted : 14/11/2019 11:11 pm
Ben Park
(@ben-p17)
Active Member

Adjust X, re-executed selftest x=280, y=295

Ben Park
benpark@knights.ucf.edu...
Posted : 15/11/2019 12:45 am
Tim
(@tim-m30)
Illustrious Member

That image suggests the printer is thinking the print has completed, nothing more to do.  Were you around when the printer stopped?  Did it beep or do anything other than just stop moving and present that screen?

The tension numbers are for understanding the actual bearing friction. They don't tell anything useful as far as belt tension goes - that's another Prusa myth.

It is always wise to get more than one opinion......
Posted : 15/11/2019 7:08 am
Ben Park
(@ben-p17)
Active Member

I have not been around when the print stops. Since it is random with respect to time, it is hard to figure out when to watch. 

However, since the x was just barely in range, I worked on increasing the tension. X=280 instead of 258. I re-calibrated and re-printed. The print finished. Don't know if that is just luck or too short of a print. I am printing one of my past failed prints as another test. 

@gautam-j - please check your belt status in case that is your issue

https://www.google.com/search?q=prusa+mk3s+belt+tension&oq=prusa+&aqs=chrome.0.69i59j0j69i57j69i60l3j69i65l2.2412j0j7&sourceid=chrome&ie=UTF-8

@tim-m30 - I will repost when the current print finishes or freezes. Regardless, thanks for the help and education along the way. 

Ben Park
benpark@knights.ucf.edu...
Posted : 15/11/2019 10:56 am
Tim
(@tim-m30)
Illustrious Member

Those reported tension numbers are meaningless.  If you try to achieve that magical 240 you will bend metal.  What the numbers indicate is motor power required to move the axis.  Lower numbers show increased average currents. Higher numbers are better and indicate smooth and free moving axes. 300 is a goal to shoot for, 280 or higher is pretty good. Lower than 260 is a problem and leads to crashes.

Here's how to test tension:

Belt Tension Calculations

It is always wise to get more than one opinion......
Posted : 15/11/2019 8:07 pm
Ben Park
(@ben-p17)
Active Member

With my X & Y above the 280 mark as explained above, I am now printing successfully. Two prints in a row. Thanks!

@gautam-j - please check your belt status and post it here.

Ben Park
benpark@knights.ucf.edu...
Posted : 15/11/2019 11:59 pm
matthew.m55
(@matthew-m55)
New Member

I had similar problems, without using octoprint.

I did observe some failures, I could hit pause, and resume (with no effect).  when I tried to do something a bit more complicated, screen became unresponsive.  At least once, the angle of the recovery from collision was wrong, and movement sounded bad.

I did regular maintenance, and noticed two screws came out of the rambo case.  In my case, i believe the screws were shorting something out.

Re-tested, and the errors where the printing just stopped went away.

Now convinced I have some small miss-alignment in the carriage that causes long moves to fail that were very specific to the object I was printing.  I tend to print hot, and have had a lot of problems since mk3s upgrade.

Posted : 17/11/2019 1:39 pm
fheatherz
(@fheatherz)
Active Member

Just had this exact same problem. Printer just stopped in the middle of  a print, no errors, heaters still on. I figured it was octoprint, but now let's see if tweaking the belts fixes it. They were both around 260, now around 278 or so.. I checked the rambo board, didn't see anything amiss. 

Posted : 22/11/2019 8:16 pm
vintagepc
(@vintagepc)
Noble Member
Posted by: @fheatherz

Just had this exact same problem. Printer just stopped in the middle of  a print, no errors, heaters still on. I figured it was octoprint, but now let's see if tweaking the belts fixes it. They were both around 260, now around 278 or so.. I checked the rambo board, didn't see anything amiss. 

If octoprint is querying temperatures while printing you may be running afoul of this issue if the printer is busy doing things.

https://github.com/prusa3d/Prusa-Firmware/issues/2105

Some programs (pronterface, *cough cough*) do not respect "busy" replies from the printer and continue spamming temperature requests. This inserts a bogus M1 (pause) command in the command buffer which looks, for all the world, like the printer has frozen. Pushing the knob resolves it if this is the cause.

The printer will often be in this busy state when doing things like bed levelling, crash recovery, filament runouts, etc. so one of those in conjunction with an ill-timed temperature query is a recipe for a pause.

Posted : 22/11/2019 8:36 pm
fheatherz
(@fheatherz)
Active Member

@vintagepc

I actually tried that - just instinct to press the button to see if anything would happen.. but alas, nada. I just assumed octoprint had barfed somehow but thought I would check it out here to see if anyone else had the same issue. It's identical to the OP - stopped, not clogged, heaters on and burning into the print, no crash noted, no errors on the screen. Time left was just dashes.. Like it was done but didn't remember to run the end script..  

this was the 'vine christmas tree' from prusaprinters - never printed it before, so could be something there, but looks like it printed well for others. 

This post was modified 2 months ago by fheatherz
Posted : 22/11/2019 8:45 pm
Page 1 / 2
Share:

Please Login or Register