DisplayLayerProgress causes layers shifts

[mdaneman]

I have been struggling with consistent layer shifts (not always at the same layer) printing thorugh Octoprint on my Prusa MK3S. Layer shifts are on the order of 0.2 to 0.5mm can would typically happen 1 to 4 times per object.
Disabling the DisplayLayerProgress plug in eliminated the layer shifts.
My Octoprint is running on a Pi3B with Octoprint 1.3.12.

[SigmaRelief]

Just to add a few voices to this, there is a thread on the Prusa forums with a number of people encountering similar issues. https://forum.prusaprinters.org/forum/original-prusa-i3-mk3s-mk3-user-mods-octoprint-enclosures-nozzles-.../octoprint-issues-layer-skipping-print-pausing/

I personally had issues with a 3B+, Octoprint 1.3.12, and DisplayLayerProgress 1.17

[OllisGit]

Hi @mdaneman ,

which version of DLP do you use?
if possible, please attach the gcode file that was related to layer-shifting.

[SigmaRelief]

Just for a bit more background, I had issues with about a dozen different files (Solidworks 2019 -> .3mf) sliced with both PrusaSlicer 2.1.0 and the two latest versions of supermerill's Slic3r++. For a while I suspected Slic3r++, but more testing showed that was not the issue. Only "small' parts would work intermittently, but it was more statistics than anything.

[mdaneman]

I had an issue with a a few of the recent DLP versions. I'm pretty sure at least 1.17 and 1.16 were causing it. I don't think I tried upgrading to 1.18. Here's a gcode file that consistently produced layer shifts (although it's far from the only one) until I removed DLP.
RobinsonCrusoe_A_0.2mm_PLA_MK3S_10h57m.gcode.zip

[OllisGit]

Hi @mdaneman ,
thanks for the gcode. Please also add the original sliced gcode from your slicer.

The current attached file was downloaded from OctoPrint and already include the "M117 INDICATOR" and need the orig. source to compare each other.

[OllisGit]

@SigmaRelief if possible please attach a "corrupt" file, downloaded from octoprint and also the "original" file created by your slices.

This would be really helpful to analyse the issue.

Thx, in advance
Olli

[mdaneman]

Unfortunately I don't have the original gcode, since I sent the gcode directly to Octoprint from Prusa Slicer. However, I imported the settings from the downloaded gcode file and resliced the objects to produce a pretty good approximation of the original.
Additionally, I don't think the file on Octoprint is "corrupted". After disabling DLP, I printed this exact file (directly from Octoprint) a couple of times with no layer shifts. I think it's more what DLP does with the info in that file during printing.
RobinsonCrusoe_A__0.2mm_PLA_MK3S_10h55m.gcode.zip

[OllisGit]

Hi @mdaneman ,

I compared each file and I didn't found any issue....
...hmmm...current assumption is that the processing of the M117 INDICATOR-Layer take to long.
E.g. calculating layer duration, extraction of fanspeed, feedrate , ... and also updating the browser-ui.
Maybe there is the race-condition: processing is still running, not done yet and the next command was executed. this is hard to proof.

One approach could be to put the processing in a parallel thread. I will try that.

[Eizock]

To add to this issue:
Using Vase-Mode to print causes the layer to change more often (alot more). With DLP i get ugly blobs and zits. Without it it works fine.
Seems to be caused by the same underlying Issue...

@OllisGit Another option would be to "preprocess" the whole G-Code file (maybe ?). (Although I have absolutely no Idea how your plugin is calculating its values...)

[OllisGit]

Hi @Eizock ,
please add the Vase-Gcode to this issue.

1. directly generated by the slicer
2. downloaded from OctoPrint.

This will be very helpfull to analyse the issue!

Thx in advance,
Olli

[Eizock]

Hi @OllisGit,

Here are the GCodes:
GCodes.zip

Although the one from Octoprint is NOT printed. Just uploaded and downloaded again. If you need a file that is actually printed, just tell me.

Also the constant layerchanges start only on layer 4 (about 1 mm up on the Z-Axis).
Hope I could help :P

[OllisGit]

Hi @mdaneman , @SigmaRelief , @Eizock
in the newest release 1.19.0 I changed the behaviour (switching to async) of processing the gcode during print. I think this was your issue, because the gcode was not send fast enough to the printer.

Because it is just an assumption, please test and give me a feedback.

Thx, in advance
Olli

[DrShats]

I also have a similar problem, but mine is bit different: when I print from Octoprint, not from SD card, printhead stutters. If I disable DLP, all ok. I run Klipper with serial connection (not USB) to Mega2560+RAMPS board. So I guess it is taking lots of resourses to replace INDICATOR.
For now I disabled DLP. Looking forward to start using it again. Cheers!
FIY I tried also on 1.19.1 version of DLP

[Eizock]

@OllisGit
With version 1.19.0 it was fixed for me. Vases and other prints work beautifully now.

@DrShats
If you tried the latest Version, maybe there is a incompatibility between Plugins you are using (?).

[DrShats]

@DrShats
If you tried the latest Version, maybe there is a incompatibility between Plugins you are using (?).

I left only OctoClipper NavBarTemp and DLP and still stutter. So I think the problem is not fully resolved. And again with DLP turned off everything is peachy

[Syl20-94]

hello, I tried also and I still have the issue on my prusa mk3S, even by reducing speed I had still layer shifting, (but less than before you fix it), so I'm not sure that completely solve the issue, I tried with and without to be sure that is not becoming of my Gcode. I use octoprint 0.17 up to date, and print from it

thank anyway for your support

[blacksurgeon]

It fixed it for me. Printed now for 18h and didn't get any layer shift.
OctoPrint 1.4.0 on RaspBerry Pi 4 OctoPi 0.17.0
PluginList:
Autoselect Plugin 0.2.0
Bed Visualizer 0.1.13
Cost Estimation 2.1.3
Dashboard 1.11.4
DisplayLayerProgres 1.19.1
Filament Manager 0.5.3
FileManager 0.1.4
M73 ETA Override 1.0.1
Octolapse 0.3.4
Preaheat Button 0.5.1
Printer Stats 2.0.2
PrintTimeGenius 2.2.1
Prusa Leveling Guide 1.0.8
Resource Monitor 0.2.2
Sidebar Temp Graph 0.1.4
Telegram Notifications 1.5.0

Edit 16.04.2020: My i3 MK3S is running very fast (printing Shields using settings from Prusa Research)

[Eddyg87]

I have had the same thing as reported on the Prusa Forum thread. By slowing the travel speed down to 150mm/s the layer shifts go away. I recently tried upping the travel speed again with the latest version of DisplayLayerProgress (1.19.1) installed and I still got layer shift. I ran the same G-code off SD card and it went away. Is there any known Debugging tool I can run to help see if this is the issue? Thanks for all your work

[mdaneman]

Ok, finally had time to check out the new version. I printed the same gcode that was producing layer shifts before (the one I posted above). I first installed DLP v1.18.1, printed the gcode and got 3 layer shifts. I then installed v1.19.1, printed the gcode again and got no layer shifts. So it seems that the issue may be solved (although it's still a small sample). I'll keep printing with this version and see if stays good.

[FixxCZ]

Installed Octoprint yesterday, having a version v1.19.1 and got a layer shift in the first longer print. I have week old i3 MK3S assembled by Prusa.

Bottom_Mesh_SM_0.2mm_PETG_MK3S_4h12m.gcode.zip

[OllisGit]

DAMNNN...that looks horrible, sorry!!
I thought that the async-way solves everything....now, only for some people.

It looks like only prusa-printer were affected ...or is someone here with layer-shifting problem (DLP1.19.1) on a different printer?

To be honest, currently I have no idea how to analyse this....but I want to mention one point: local vs sd card-upload

Local
upload goes to the pi. OctoPrint can listen on gcode and could adjust it (like DLP)
SD
goes over the serial connection to the SD card in the printer. During the print OctoPrint can't listen/manipulate gcode, because it is directly send to the print (DLP don't work). Datatransfer is faster.
More information, see https://community.octoprint.org/t/ouch-sd-card-vs-octoprint-what-a-difference-help/8618

Also see https://community.octoprint.org/t/layer-shifting-only-when-using-octoprint-bis/14266

[FixxCZ]

I was using that Local method. Is the SD method just loading it to the SD card in octoprint or run it from SD via printer interface?
I disabled the Layer Progress plugin and had three four hours prints and all is working fine.
However I like this plugin and Dashboard cryies without it and I would love to use your print history plugin (that doesn't work for me as I installed latest Octoprint).
Let me know if I can help you anyhow, like trying to invoke layer shift with debuging enabled.

[FixxCZ]

Today another layer shift even with plugin disabled. I will try to uninstall it completely to eliminate it's impact. But maybe it's something else. It eve got two shifts on X and Y hours after each other. I'm going to print it in safe mode.

[gdombiak]

Thanks @OllisGit ! Stars are aligned. Good catch on the numbers :)

It would be good to be super clear about how to test the fix since as you said there are multiple reasons for layer shifts. The conditions should be:

1. Before installing new version, make sure you have a gcode file that produces a layer shift when plugin is enabled and that there is NO layer shift when plugin is disabled
2. If you meet criteria above, then install new version and restart OctoPrint so new version becomes active
3. Start new print with gcode that produces a layer shift
4. Report back results :)

[gdombiak]

@OllisGit , yes I'm using the professional editirion. Jetbrains kindly provided me a free license for open source development. I think that this plugin qualifies as well since it has been around for some time and is in active development and the license is good.

You can still use Yappi (free profiler) and some free visualizer tools (kcachegrind) for this analysis even if you do not have them integrated into PyCharm.

[gdombiak]

I created this new plugin for profiling OctoPrint. https://github.com/gdombiak/OctoPrint-Profiler. It is in its infancy but it is already useful. To narrow down an exact analysis on a particular method of your plugin, I disabled the profiler plugin and instead added a few lines of code to your plugin. Both things are needed to do coarse grain and fine grain analysis.

[OllisGit]

Hi @gdombiak ,

I already used your Profiling-Plugin, looks good.
I will try to ask JetBrain for a pro. version.
Thx again
Olli

[OllisGit]

low: my pycharm prof. licence arrived, now I can profile everything, great!

[SigmaRelief]

Good news, I think the latest release is on to something. With update printer display off, I have printed 50 hours and no issues. I was post 2 and have had persistent issues with all releases. I will experiment with turning on more options, but previously I had crashes with the current settings. For reference, I am using a Prusa Mk3S with a lightly modified copy of Vertigo235 firmware.

[gdombiak]

@SigmaRelief that is great to hear. @Willmac16 did some tests using the new optimized version and leaving settings on and he got no layer shifts. Same test using previous version did produce layer shifts. Let us know if you see same results or not.

Thanks,
Gaston

[Celcius1]

I think the layer shift has been solved as I did a print with the latest marlin firmware in the bug fix branch and shift has not occurred.

I'll reenable my disabled plugins and do another test.

[Jack-Dark]

@OllisGit I assume this issue can be closed now? It's marked as included in the bug-fixes for the latest release and there's no activity for about a month now.

[ddm-j]

Agree with @OllisGit many things could cause this problem. I manage a print farm and can confirm that the layer shift still exists on 4 of my Prusa Mk3s and my Mk2.5s MMU.

I like the plugin for it's ability to show progress in the text on the tab in browser. Otherwise, I have to disable to maintain farm output!

[gdombiak]

Hi @ddm-j, trying to confirm what you reported. Using the latest version of the plugin you see layer shifts in your farm but they are not present when the plugin is disabled? And this is printing the same part?

Thanks,
Gaston

[ddm-j]

@gdombiak exactly! Latest version. The problem seems to be exacerbated by increasing the feedrate. Something that is common practice here for daily queue scheduling.

I've experienced it both with repeated prints of the same file (failure occuring at the same Z height). And across multiple production files on different printers - again usually around the same Z height (5-10mm).

I've noticed that on files with a high aspect in the Z (tall and skinny) do not suffer this issue. While parts with high aspect in the X&Y are most commonly afflicted.

I can confirm that disabling has remedied the issue. However I will allow several more days to see if the problem is gone!

EDIT: I should note that I have a few printers (Mk3s) that have not shown any problems.

[Eddyg87]

@ddm-j I have seen this where if I have the travel speed cranked up to 180mm/s I can see layer shifts. I currently keep it down to 150mm/s and don't tend to see it. I can't really test at the moment as printers are quite busy.

[ddm-j]

@Eddyg87 I plan on allocating a printer for testing next week. But we've established a safe range of feedrates where we can expect minimal errors - and we experienced shifts within these margins this with the plugin enabled.

I guess all of my commentary can be taken as conjecture because I haven't really done any real testing yet. Just a hypothesis that has been somewhat confirmed today in our farm.

[ID4600]

I'm having the same issue here, i'm printing on a Creality Ender-5 plus, with DLP turned off everything runs fine, with it turned on it skipps on random places, sometimes 2 times, sometimes only once or worse.

RaspberryPi 3 b+
Running Octoprint 1.4.2
DisplayLayerProgress Plugin 1.24.0

Printspeed 50mm/s
movement speed 150mm/s

[richardjharding]

I think I may have the same issue - Prusa Mk2.5 - checked belt and pully, replaced bearings, replaced stepper on y-axis until I found a mention of octoprint and this plugin on prusa forums - remembered my issues roughly coincided with me adding this plugin
Can't say for sure of course but ran the same print I was having issues with both from SD card and from octoprint with DisplayLayerProgress disabled and all fine - with it enabled I was get a couple of 2- 4mm skips almost always in y-axis but occasionally in X

Reducing print speed on the prusa to 70% dramitally reduced the degree of shift but it still occurred

I'd be happy to help with any logs or test prints if it helps confirm or diagnose the root cause

Octoprint 1.5.0
Python 2.7.16
OctoPi 0.17.0
raspberry pi 3b+

[MikePfaff]

Did anyone try to download an affected GCode file (causing layer shifts and already modified by the DLP plugin at upload time) from OctoPrint and put it onto an SD card and run it directly on the printer? That way we could at least narrow it down to either a) an issue with the GCode modifications done by the DLP plugin or b) an issue with how the Prusa firmware handles M117 commands. An interesting fact about the Prusa firmware is that M117 commands are processed before any other commands (Marlin_main.cpp, early on in the function process_commands()), with the source code comment even saying

moved to highest priority place to be able to to print strings which includes "G", "PRUSA" and "^"

I wonder whether there is some kind of strange M117 command related race condition being triggered in the firmware? That could explain why it seems only/mostly Prusa printers are affected.

By the way: There is a related/similar issue reported against OctoPrint directly: #3524 - Multiple layer shift when printing from OctoPrint

[Jdbye]

I have been having issues with layer shifts recently and incidentally, I installed this plugin not that long ago.
What seems to happen is that my print pauses for several seconds (around 10-20 seconds) multiple times throughout the print, leaving blobs. This happens multiple times in every print although it doesn't always cause issues, but when it happens early on in the print, it leaves a blob sticking up far enough that the next time the hotend passes over it it makes a loud crashing sound and causes a layer shift, sometimes multiple times on the first few layers.
It seems to happen at the end of layers.

FWIW I did try enabling Z-Hop When Retracted and it did nothing to solve the issue.
Layer shifting has been happening consistently on the same prints every time, and always early on in the print, likely since later on in the print any blobs just get lost in the infill. That doesn't mean it couldn't happen later too (depends on where exactly in the print the pauses happen, if it happens on a solid layer it could still be bad) just that it's far more likely to cause problems when it happens on the first few layers.

My prints didn't use to have long pauses like this. There were some occasional pauses, but not for much more than a couple seconds (not long enough to cause any big blobs) and only on certain prints, likely the printer being overloaded with G-Code. Long pauses on everything I print is something that started recently. So I can only assume it has to do with this plugin, I've just disabled it and am retrying the print.

For the record, I'm using a Geeetech A20M.

[Jdbye]

So far so good. Progress 64%, I heard it pause 3 times but it was just a few seconds each time and didn't leave a big blob. No layer shifting. But it's only the second time I attempt this print, so I can't say for sure. In the next days/weeks, I am going to retry an especially problematic print that kept failing with layer shifting in the first layers every time, I tried it 5-6 times, it was just not possible to print without issues. Not looking forward to it though as it is a long print (so I've been putting it off)
If that also goes well with the plugin disabled, then I'm pretty certain what the culprit is.

[jolcese]

I'm still facing the same issue on a Prusa MK3S+ using the latest version of DLP (1.25.4)

[TheGreatGonzolio]

Issue still exists and happens during M74 commands. Prusa Mk3s+

[drejc]

This issue was gone for some time on my Prusa MK3s paired With OctoPrint 1.7.2 running on OctoPi Version 0.17.0 / Raspberry Pi 3 Model B Rev 1.2.
But since I have updated to DisplayLayerProgress 1.27.2 it reappeared. It is not as severe as it was before and it happens every 3 to 4th print. But still very annoying so much I have disabled the plugin for now.

[enz1ey]

Just checking in to say this is apparently still an issue for some, including myself. I have eliminated every other possible cause. At first, I thought it was a bad/poor SD card so I bought an SSD adapter. I thought the Pi was overheating, but after installing a fan it stays under 40C. I thought it was the USB cable, so I replaced it and taped the 5v pin.

Still, every print over 8-ish hours results in a layer shift of roughly 1mm on the Y axis. I uninstalled the DisplayLayerProgress and I've been printing nonstop rounds of nearly 12-hour prints for three days without a single layer shift.

I just started using these Pis after they were in storage for a while but they worked perfectly about 8 months ago. It makes sense that whatever release of the plugin I was running at the time was fine, but since reinstalling them and using them again, the plugin was updated to the latest release and somewhere along the lines, this bug was reintroduced.

For now, I can do without the plugin. I miss having the ETA in my browser tab, but that's not worth suffering with layer shifts on long prints.

[drejc]

Just to confirm ... it happens on my setup as well ... very seldomly but it happens / let's say once every 20 prints. I could not replicate the circumstances, but I have a suspicion it has to do with models that have a lot of short movements as it appears on intricate parts more often then on simple ones.

[credomane]

I had been playing with this issue off/on for a long while and I was starting to believe the problem lay with marlin on 8bit chips as I haven't been able to reproduce the problem on a 32 bit chip or an 8bit chip running klipper. Both of my active 3d printers are running marlin on 32bit boards for over a year now, and like I said I haven't had the issue on them, so I've quit investigating by default.

I've lost my little python script that I made or I'd post it here. It would open the serial port of the printer and send a m117 message (had a cli option to specify a fixed string or random one of whatever length desired) to the printer at 0.01-1.0 seconds intervals that would change every A minutes all the while continuously jogging the printer along the x for A/3 minutes, then y for A/3, then x/y for A/3 using commands to move 5mm or less (these were random each move or fixed depending on what I decided that day) but with multiple queue up. Far as I can determine, the problem happens at random and the printer decides to move in the opposite direction for a particular gcode move but the printer thinks it moved in the correct direction. Every time I'd think I was narrowing down the range to a specific repeatable cause (particular M117 combined with a certain movement) it would suddenly quit happening even when widening the range back out. It was so frustrating.

I've even managed to make marlin move in the opposite direction a few times from the LCD menu! It was when this happened that I started to investigate the problem somehow being marlin itself. Know it wasn't a me problem because the main status screen would say the bed was at Y235 but the bed was very clearly not anywhere near that location.

Looked all through the marlin source and I can't make head-or-tails where the issue might be as my grasp of C/C++ isn't advanced enough to understand the inner workings of marlin. I'd make a wager that somehow there is some kind of conflict between the serial input/parsing/handling of M117 (or maybe all gcode) and the interrupt(s?) for the steppers.

[enz1ey]

Just to confirm ... it happens on my setup as well ... very seldomly but it happens / let's say once every 20 prints. I could not replicate the circumstances, but I have a suspicion it has to do with models that have a lot of short movements as it appears on intricate parts more often then on simple ones.

That's a good point about smaller models. Most of what I'm printing is 12-20 small parts at a time over 8-12 hours.