Octoprint issues - layer skipping, print pausing  

  RSS
Aljrob
(@aljrob)
New Member

Hi all,

Pringing on a 2 month old Mk3S which had performed perfectly until this week.  I've had Octopi up and running on a Pi 3B+ for a few weeks with many successful prints behind me.  I'm in the process of building a Lack enclosure and so have been running a number of long print jobs to produce the parts needed and have had several print failures, typically due to layer shifting.  The layer shifts are sporadic occurring 2-3 times in 12-24hr print jobs, pretty regular in size and approx 2mm in scale so I initially suspected a single tooth slip on the belts was to blame.

To try to address this I have tightened belt pulleys, re-tensioned the x & y belts, packed the x-carriage toothed zone with plastic shim and lubricated the linear bearings.  Whilst I now have 2 belts that are showing as within-spec on the belt status screen (c. 265 for both x & y) the layer shifts kept occurring.

Until, that is, out of sheer frustration I tried printing from the SD card directly rather than Octoprint.

The first issue I discovered, into which I'd appreciate any insight anyone can offer, was the print job pausing fairly regularly early on the first layer.  I solved this by disconnecting the Octoprint USB cable, following this the first layer completed reliably.  Also, once I'd done this, the print job completed flawlessly, absolutely no layer shifts.

My questions are:

1) Can anyone shed any light as to why the first layer is failing whilst Octoprint is connected via USB to a Mk3S which is printing from the SD card? Obviously disconnecting the printer is an easy fix but I'm sorry to lose the remote-monitoring capability.

2) Similarly, has anyone else experienced layer shift issues with Octoprint?   Is it simply co-incidence that my first long SD print job completed successfully where Octoprint attempts had repeatedly failed?  Is there any way to fix this?

Thanks in advance for any thoughts/insights anyone can offer.

Aljrob

Posted : 25/11/2019 10:18 am
mdaneman
(@mdaneman)
Estimable Member

I currently see Octoprint related layer shifts. I see no shifts if I print from SD. I also seem to not have shifts when running Octoprint in safe mode (re verifying this tonight). So I’m assuming that one of my plugins is to blame. The funny thing is that I’ve been running with these same plugins for months with no problem. I don’t see the first layer issue just from RPi being plugged into the printer that you’re seeing though. 

I'm curious how Octoprint can cause a shift. I thought that all the extruder moves are in absolute coordinates, so even if the printer misses a move command, the next move should bring it back to the correct position. How does the whole print location shift at a certain layer? Am I missing something? Most likely. 

Posted : 17/12/2019 7:10 am
david.a66
(@david-a66)
Honorable Member

check the printer crash detection counters - I bet you are having crashes

Posted : 17/12/2019 4:50 pm
mdaneman
(@mdaneman)
Estimable Member

Can’t speak for the OP, but for me there are zero crashes and I’m 100% certain that the problem is Octoprint related. Im currently enabling my plugins one by one to see which one is causing the layer shifts. 

Posted : 18/12/2019 3:59 am
Aljrob
(@aljrob)
New Member
Posted by: @mdaneman

Can’t speak for the OP, but for me there are zero crashes and I’m 100% certain that the problem is Octoprint related. Im currently enabling my plugins one by one to see which one is causing the layer shifts. 

Me too - I’ve re-flashed a clean Octopi image and am now able to print without layer shifts once again.  

Current installed plug-ins are:

Octolapse
DisplayLayerProgress
Dashboard

Posted : 24/12/2019 11:46 am
alvaro
(@alvaro)
Eminent Member

When I powered my Pi4 directly from the board I had serial transmit issues, I bet you are skipping g-code lines.

I never made it that far, but test printing with the Pi power from a 2 amp USB phone charger.

Posted : 02/01/2020 12:24 am
aaron.m23
(@aaron-m23)
New Member

I can’t offer anything very scientific yet, but I will say octoprint has been driving my mk3 from day one with no real issues (this has been since shortly after the mk3 was released). I didn’t do any real printing for months, but am back at it now. I applied the latest firmware to the printer and upgraded my OctoPrint to 1.3.12 a couple of weeks ago and did a few short prints with no problems.

Last night I printed Part II (the short one) of the two for the mk3s upgrade I’ve had sitting around forever. I did the short one because I wanted to confirm the PETG behavior was good. I’m using the Prusa gcode, not slicing the STLs myself (figuring they have it dialed in for this job). This 1.5 hour print went perfectly.

I started the 10 hour Part I print last night and it completed, but I found a significant layer shift in X in the print. The printer error log showed no crashes or errors of any kind in the last print. This was using OctoPrint to send the gcode (same as always). 

I’m reprinting it now, but I’ve placed the gcode on the SD card this time and OctoPrint is simply monitoring. 

Again, this is a single incident... but I happened to be catching up on the forums a bit last night while this print was running and saw a few recent layer skipping threads, so it was in the back of my mind. When I found this has happened (absolutely a first time for me after many prints over more than a year), I thought it worth mentioning. I won’t rule out some calibration in my printer since it was idle for a long time and was moved recently... but the few hours of printing prior to this long one did go without any incident with my normal OctoPrint config.

Anyone made any definitive discoveries since the last posts? I have some long print jobs coming up and would really prefer to have the reliability I am accustomed to with my normal setup. 🙂

Posted : 05/01/2020 2:42 pm
Robert-mm200
(@robert-rmm200)
Prominent Member

If I was suspicious of OctoPrint and had a long print coming up, I would put that file on SD card.

Disconnect the Pi from the USB port. Print. And maybe say a small prayer.

Enough things to worry about in a long print without adding OctoPrint to the list. And I print everything from OctoPrint...

Posted : 05/01/2020 5:19 pm
mdaneman
(@mdaneman)
Estimable Member

@aaron-m23

I’ll be curious to see how it looks printed from SD and whether you continue to have issues with Octoprint. In my case, I printed from Octoprint for months with no problem and then started having an layer shift issue on almost every print until I got rid of a bunch of Octoprint plugins or ran in safe mode. I’ve since been running with limited plugins without a problem and have been adding back plugins one by one. I recently started seeing layer shifts again after enabling DisplayLayerProgress and Dashboard.  However I’m still puzzled why everything was fine previously running with the same plugins. I wonder if there’s some interaction between Octoprint and something in the hardware.  Still everything I’ve printed from SD so far has come out fine. 

Posted : 06/01/2020 2:10 am
Robert-mm200
(@robert-rmm200)
Prominent Member

Everything said so far makes it sound like OctoPrint with a lot of plugins is not keeping up with the Einsy data requirements.

You seem to be getting into an under-run situation on the Einsy side. Results may be unpredictable.

Might be an argument for a Pi 4...

 

Posted : 06/01/2020 2:22 am
aaron.m23
(@aaron-m23)
New Member

So the SD version printed just fine. Granted, this is one OctoPrint failure and one SD success, so hardly definitive proof... but it falls in line with other anecdotes in the forums. 

While the SD job was printing, I poked around in OctoPrint a bit. I don’t have a crazy number of plugins, but there are a few. At this point I don’t recall which (if any) might be relatively “standard” to the install. It’s been a good while since I did this install on the Pi 3B it’s running on and applied whatever plugins I felt I needed. Among them are OctoSlack that sends updates at 20% intervals including a still image from my webcam. 

The one error that stands out is a repeating error every few minutes from a TP-Link smartplug plugin I have that allows me to power the printer on and off remotely. I don’t appear to have many or any of its automated behaviors enabled (like shutoff in a thermal runaway condition, etc... likely worth exploring). But the repeating error is a failure of OctoPrint to give the plugin a status update on the print job. Not sure it has any bearing since it’s going on every few minutes (I didn’t know this until I looked at the logs today)... but I’d like to correct it if just to tamp down the log noise. 

I was not running any time lapse recording, BTW. For what it’s worth, the shift appeared (by measuring with a small ruler) to be right on about the 5mm height point. Also, it’s worth mentioning that I had OctoPrint plugged in the whole time the SD job ran, it continued to send me Slack notices just fine and it logged those TP-Link errors the whole time. But there was no layer shift in this case since it wasn’t the GCODE sender.

I’ll keep you posted with more as I have time to get more analytical through repeated, consistent tests. 

 

Posted : 06/01/2020 3:30 am
mdaneman
(@mdaneman)
Estimable Member
Posted by: @robert-rmm200

Everything said so far makes it sound like OctoPrint with a lot of plugins is not keeping up with the Einsy data requirements.

You seem to be getting into an under-run situation on the Einsy side. Results may be unpredictable.

Might be an argument for a Pi 4...

 

That could be it.  It's just strange that for me it always produces a layer shift in X-axis.  I would think skipped commands would result in defects in the part at specific locations rather than a layer shift for all layers after that.

Posted : 06/01/2020 6:04 am
Robert-mm200
(@robert-rmm200)
Prominent Member

Are GCode moves relative - or absolute? If they are of the form Move 100 units in the X direction, you can see how losing a few would mess up everything after.

If they are of the form Moveto position x 100 Y 150 - I have no explanation unless a crash got involved. The printer must have lost it's Home position.

Posted : 06/01/2020 6:28 am
mdaneman
(@mdaneman)
Estimable Member

As far as I can tell both Prusa Slicer and Cura use absolute coordinates for X and Y moves.  They have a "G90 ; use absolute coordinates" command in the starting G-code.  That's why I find it very odd that Octoprint can cause layer shifts.

Posted : 06/01/2020 7:32 am
AxioN
(@axion)
Active Member
Posted by: @aljrob

has anyone else experienced layer shift issues with Octoprint?

YES! OMG I have been pulling my hair out trying to figure out what was going on. I also, on a whim, tried to print the same exact gcode file directly from the SD card with 100% success. I wasted so much PETG attempting to print things before trying this.

I have found that printing PLA files work fine from Octoprint, but when I print anything PETG, the shifting occurs and it is random as to when. I have NOT tried printing a file I would have normally printed in PETG with PLA to confirm. My printer and Pi are connected to a UPS with AVR.

What am I doing here? Narf!...
Posted : 16/01/2020 2:03 pm
AxioN
(@axion)
Active Member

Some more information:

Every time there was a shift it happened on the Y axis. My printer is right next to my computer, so I can monitor it. Every time the shifting occurred there was a loud ca-chunk  sound, then it would shift 1 to 2mm; it is the same sound as when you run the XYZ setup to find home and it is testing the boundaries; so it sounds like a collision. The crazy thing is I saw it do this and the print head makes no impact when the shifting and sound occur. I thought there was something wrong with the rods, belt, or motor. I first tried adding more lubricant then I disassembled the Y axis and re-assembled, looking for problems (scratches in rods, filament pieces in belts, tightening screws, tightening belts, etc); nothing changed. 

What am I doing here? Narf!...
Posted : 16/01/2020 2:11 pm
Robert-mm200
(@robert-rmm200)
Prominent Member

Silly thing that gets a lot of folks is the Y Axis zip ties. Not trimmed, installed incorrectly, etc. Make sure the zip lock is positioned exactly like the picture in the manual.

Second common problem is a drooping cable, that hits the carriage at some point. Drooping cables also flex and break wires. Watch out for that.

Posted : 16/01/2020 6:07 pm
alvaro
(@alvaro)
Eminent Member

Turn off all your plug ins and try again.  The time laps plug ins inject code.... 

Posted : 16/01/2020 7:07 pm
Share:

Please Login or Register