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.

[foosel]

@OllisGit I want to put out a PSA about this via the plugin notification mechanism since it seems to affect quite a number of people and I keep getting pings about that... Is this accurate:

Some users are experiencing layer shifts that seem to be caused by this plugin. If this affects you, please disable it for now and follow the discussion found at the "Read more..." link below.

If yes I'll push it as a plugin notification for all versions (or is there a confirmed lower limit?) linking back to this ticket.

[Musaihelan]

Hello, I face this problem in MINI prusa, some printing are good but some are as per the pic. The first print were good and all test is good. Leveling is : -0.60 / -0.65 Can any one will help me

[Minglarn]

Using RPI3+ and facing some hard stuttering while printing in VAS mode. A small object is impossible to print clean and continuously. When DLP is disabled the print actually prints quite nice...

Really like the DLP as it gives me good info for my Dash-panel in the living room..

[gdombiak]

First time I see this thread. @OllisGit, since printing same uploaded file works fine when plugin is disabled then modified gcode is not the reason. Adding async processing helped but not for everyone. Based on this info I’m curious what a profiler would show us. At the moment I’d suspect this is a cpu (memory less likely) consumption issue. Some hardwares can handle it better than others. Have you tried profiling your plugin?

Gaston

[OllisGit]

Hi @foosel ,

good idea!

Yes, please add your suggested Notification-Message (I didn't know that this is possible).

Some users are experiencing layer shifts that seem to be caused by this plugin. If this affects you, please disable it for now and follow the discussion found at the "Read more..." link below.

If yes I'll push it as a plugin notification for all versions (or is there a confirmed lower limit?) linking back to this ticket.

Currently, I have no idea why the last improvements now works for several people, but it didn't work for others.

Thx, Olli

[foosel]

I've pushed it for 1.17 through the current version for now. 1.17 was the earliest confirmed version with the issue I could find mentioned in this ticket.

Here's a list of the currently registered notifications.

[OllisGit]

Hi @gdombiak, I think you hit the nail on the head.

Profiling could be one option, but I am not sure how I should I implement this. Of course I can execute some method with a profiler and see some improvments, but what is the "final target".

Currently I prepare a new release where I changed the whole gcode-processing.

[corporategoth]

I will chime in that I've seen this issue too. Usually on large prints. I should mention I am on a Pi Zero right now (I might upgrade), so CPU oomph might be a factor.

Most prints have printed fine, however two of my large prints have had a layer shifts. I only installed this days ago, so I have always been on 1.19 I believe.

I should mention I downloaded the gcode, and compared it to the ones I sliced from PrusaSlicer, and the only difference is the M117 INDICATOR-LayerX lines.

[pablopeu]

Cero problems with an Anycubic Kossel Delta Plus running Octoprint on a Raspi 3b+

[foosel]

What I still don't understand here is how this can even cause layer shift in the first place. I can see stuttering being a result if the sending gets delayed too much, yes, but in no way should a lack in planned moves in the firmware's planner buffer (which too big delays here would cause) lead to actual layer shifts. I can see two things that cause a layer shift (apart from mechanical issues mind you): one is a hiccup in the actual stepper control routine. That would be on the firmware though. The other is mangled coordinates sent to the printer. Do you do any kind of rewriting of commands by any chance?

All this is really weird. I really struggle to see how a plugin (or OctoPrint itself for that matter) could even cause layer shifts. Again, stuttering I can see. But full blown coordinate shifts without messing around with the sent lines?! 🤔

[dxgldotorg]

Thanks, thought my magnetic bed was shifting.

[Eddyg87]

What I still don't understand here is how this can even cause layer shift in the first place. I can see stuttering being a result if the sending gets delayed too much, yes, but in no way should a lack in planned moves in the firmware's planner buffer (which too big delays here would cause) lead to actual layer shifts. I can see two things that cause a layer shift (apart from mechanical issues mind you): one is a hiccup in the actual stepper control routine. That would be on the firmware though. The other is mangled coordinates sent to the printer. Do you do any kind of rewriting of commands by any chance?

All this is really weird. I really struggle to see how a plugin (or OctoPrint itself for that matter) could even cause layer shifts. Again, stuttering I can see. But full blown coordinate shifts without messing around with the sent lines?!

If it's any help there has always been a loud audible clunk when my printer has done it and the crash detection routine does not pick up the layer shift.

[szafran81]

Just want to put my 2 cents here for information purposes.

I have a Prusa MK3S MMU2S. Firmwares: MK3S: 3.8.1 MMU2: 1.0.6 Always using latest stable PrusaSlicer for slicing files.

It's printing almost 24/7 - from small things that take about an hour up to 90h long prints (single and multimaterial prints).

Updated to the latest stable versions of OP and all my plugins (DLP included).

I never had anything that resembles this issue.

But it's worth to mention that my OctoPrint setup runs on a Dell 3020m mini PC with 4c/4t i5-4590T CPU.

[spiff72]

Could this issue be causing some sluggishness in the actual print moves (as well as layer shifts)? I started printing from SD recently because I could actually see the machine slowing down during prints and it was causing some print quality issues.

I would just disable the plugin, but I want to also disable Octodash (which runs a touchscreen display connected to the Pi3), which requires this plugin, but I can't figure out how to disable that temporarily without just uninstalling.

[MihleTX]

I was having the same issue with layer shifting on both of my MK3S printers on the X axis. I went so far to think I had belt issues on one of them that was doing it more regularly and after teardown and rebuild (due also to needing to have better PINDA support from Pinda drooping) , I encountered the same shifting again. It happened at the same layer of something I printed twice on two different machines....that got me thinking it was weird and not mechanical issue. I printed the same thing on my Creality printer.....and it worked just fine. Any chance it has something to do with MK3S boards

I then printed a case (similar to the one pictured an above thread and it too shifted layers early on in the build.

I am running 2 Prusa MK3s and 1 Creality CR-10 for reference. Both MK3s had issues - CR-10 did not on the same print. Exact same configs for all 3 OP for each printer.

[OllisGit]

Wow, a lot of people watching this issue, so many comments in a short time!

As I already mentioned I have no explanation right know, but I release a new development release: https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/download/1.20.1dev/master.zip

What is changed:

• since V1.7.0 (25 May 2018) I switched the OctoPrint-Gcode listening hook (https://docs.octoprint.org/en/master/plugins/hooks.html#octoprint-comm-protocol-gcode-phase). I switched from "queuing" to "sending" for more accuracy.
• Now I switched back in release 1.20.1.dev, because "sending" use the communication-thread and maybe also the adding to the async-queue takes too much time....now the communication between OP and printer is not interfering by the plugin. Now it is queued and the output is a "little bit behind", but I think that doesn't matter.

Could someone, who has this issue with the DLP release 1.19+., trying to use the new dev-version and give us feedback? That would be really helpful!

Thx in advance Olli

[spiff72]

Wow, a lot of people watching this issue, so many comments in a short time!

As I already mentioned I have no explanation right know, but I release a new development release: https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/download/1.20.1dev/master.zip

What is changed:

• since V1.7.0 (25 May 2018) I switched the OctoPrint-Gcode listening hook (https://docs.octoprint.org/en/master/plugins/hooks.html#octoprint-comm-protocol-gcode-phase). I switched from "queuing" to "sending" for more accuracy.
• Now I switched back in release 1.20.1.dev, because "sending" use the communication-thread and maybe also the adding to the async-queue takes too much time....now the communication between OP and printer is not interfering by the plugin. Now it is queued and the output is a "little bit behind", but I think that doesn't matter.

Could someone, who has this issue with the DLP release 1.19+., trying to use the new dev-version and give us feedback? That would be really helpful!

Thx in advance Olli

I am willing to give this a shot on my MK3S - especially if it provides any improvement over the stuttering/slowness mentioned above. I have had some inexplicable layer shifts over time, but the stutter/speed issues I noted above are my biggest concern.

I have a print running now where DLP and Octodash are disabled, but when it is done (about 2 hrs) I will try the new dev version.

To install do we just point the plugin installer to the link above? (use that link in the "...from URL" installer)? And if so, should I uninstall the current version (1.18.1) first?

[OllisGit]

@spiff72 just use the mentioned "from URL" button and the master.zip - URL.

The plugin manager will uninstall the old one and reinstall the new one.

[OllisGit]

@spiff72 I just realized that you are working with Version 1.18.1. This one is working in the old way. People reported that the root-issue is still there with Version 1.19.0.

Please do me a favour and just install the official release plugin Version 1.20.0 and test it!

I need feedback from users that reported the issue with 1.19.0, or 1.20.0

[spiff72]

ok i will try 1.20.0 thanks!

[spiff72]

UPDATE: Just ran the install and saw it uninstalled 1.19.1 so i was mistaken on which version I had. Should I go ahead and try the dev version instead? I am proceeding with the dev version to see if I see any issues.

[thegarbz]

I've only been using this plugin since the 19th so I've printed a bit on 1.20.0. Potentially related but I had my first ever layer shift on the only object I've printed since installing this plugin 2 days ago.

But it wasn't until today that I suspected it since I changed a lot on the Raspberry Pi 3+ (Moved from Octoscreen to Octodash which mandated the installation of this along with several other plugins).

/EDIT: Dev plugin just installed. Need to reprint an almost identical object the one that failed yesterday. Will report progress for what it's worth with my small sample size.

[rowbotik]

I’m fairly certain I upgraded to this version the day it was launched. I haven’t had any layer shifts ever until the 17th and had it multiple times since then. I’ll install this version after my current print and report back.

[jaisor]

Updated to 1.20.0 yesterday and woke up to a layer shift this morning. First time having such a dramatic layer shift on this printer without obvious mechanical reason (catching on something)

I am not running OctoPrint on a Pi. Instead, using a docker container on Alpine Linux running on x86 Intel i3, in case that is relevant.

EDIT: Just dug around the logs, previous version was DisplayLayerProgress Plugin (1.19.1) - no issues, been running it for a while, probably since it came out.

I can upload octoprint.log from the last few days if needed.

[spiff72]

I've only been using this plugin since the 19th so I've printed a bit on 1.20.0. Potentially related but I had my first ever layer shift on the only object I've printed since installing this plugin 2 days ago.

But it wasn't until today that I suspected it since I changed a lot on the Raspberry Pi 3+ (Moved from Octoscreen to Octodash which mandated the installation of this along with several other plugins).

/EDIT: Dev plugin just installed. Need to reprint an almost identical object the one that failed yesterday. Will report progress for what it's worth with my small sample size.

I am running a similar setup, using Octodash. I am partially tempted to upgrade to a Pi4 for my octoprint machine, but I suspect I will run into some roadblock with the cables (since my screen has some ribbon cables with full-size HDMI connectors, vs the mini (or micro) connectors for the Pi4).

I will add that I haven't seen layer shifts for at least a month - so I am not likely suffering from the same layer shifts described here. I actually blamed mine at the time on high travel speeds and dropped them to 80mm/s.

[radimsejk]

I have RPi 4B and Prusa MK3S setup with this plugin and a lot of layer shifts. I have disabled the plugin and voila layer shifts are gone.

DisplayLayerProgress v1.20.0 Octoprint 1.4.0 OctoPi 0.17.0

[MihleTX]

I have it installed and I will be testing with a couple of new prints…. I will update after I am done. I need to print something specific off, then I will also try a test cylinder after.

Michael

On Apr 21, 2020, at 10:23 AM, OllisGit notifications@github.com wrote:

https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/download/1.20.1dev/master.zip https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/download/1.20.1dev/master.zip