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.

[thegarbz]

@OllisGit From my limited sample size of one each I can report I had layer shifting on 1.20.0 but no layer shifting on 1.20.1dev. Too small a sample to declare it a success. Will print more tomorrow. Prusa i3 MK3S

[MihleTX]

Success on 2 of 2 prints so far on the new dev release.

I might also mention another very odd behavior that I experienced in one of my prints on 1.20 was that my printer kept on randomly stopping and engaging a filament change (as if I was changing color). In the middle of the print, it was happening nearly at every z change for like 4 or 5 times. Then it went back to printing just fine and finished the entire print. In that case - I did not experience any shifting in the print, but it was other random behavior that I had never experienced prior to the release of 1.20.

Michael

On Apr 21, 2020, at 3:10 PM, thegarbz notifications@github.com wrote:

@OllisGit https://github.com/OllisGit From my limited sample size of one each I can report I had layer shifting on 1.20.0 but no layer shifting on 1.20.1dev. Too small a sample to declare it a success. Will print more tomorrow.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/issues/124#issuecomment-617387553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWGQ6ALVXW4QQXFLBFD2YLRNX4SDANCNFSM4LCJGSJQ.

[foosel]

Just to satisfy my morbid curiosity, are we really only seeing this on Prusa printers so far? Because I'm starting to think there's a firmware bug in play here somewhat. As I said, layer shifts due to underrun of the planer buffer doesn't make sense.

[GregoryGHarding]

Just to satisfy my morbid curiosity, are we really only seeing this on Prusa printers so far? Because I'm starting to think there's a firmware bug in play here somewhat. As I said, layer shifts due to underrun of the planer buffer doesn't make sense.

Anycubic Chiron here, i think you may just be seeing more prusa due to it being one of the most popular

[jimmykl]

+1 layer shifting Prusa, gone with plugin disabled

DLP 1.20.0 Octoprint 1.4.0 i3 MK3S 3.8.1

[MihleTX]

As I said in my first post - I did not see the shifting in my Creality printer after having issues with both of my 2 Prusa MK3s printers. It very well could be a Prusa isolated issue.

M

On Apr 21, 2020, at 4:51 PM, Gina Häußge notifications@github.com wrote:

Just to satisfy my morbid curiosity, are we really only seeing this on Prusa printers so far? Because I'm starting to think there's a firmware bug in play here somewhat. As I said, layer shifts due to underrun of the planer buffer doesn't make sense.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/issues/124#issuecomment-617432945, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWGQ6HZ23SAQLL24NRXZMLRNYIORANCNFSM4LCJGSJQ.

[blacksurgeon]

Hi, this is kinda strange... 1.19.1 fixed it for me already. Still i updated to 1.20.1-dev0. Layer shifts are gone. Gone through 1 kg filament till now and it works perfect for me. MK3S here. Firmware 3.8.1-2869 Octoprint 1.4.0 on Pi 4

[mitchcecg]

For what it is worth I have had unexplained layer shifts on both my cr-10 and my ender 3 pro. I have disabled the plugin and will see if the issue goes away. I hope this is helpful

[sirl19]

I have a Creality Ender 3 Pro and a Prusa-like Athorbot A01 (that is actually a Hictop clon). I've had layer shifts on the Athorbot, but not yet on the Ender, both printing fairly long files that had been printed successfuly before. I've dissabled the plugin (version 1.20) on the Athorbot for now,

Both printers running Octoprint 1.4.0 on different RPi 3B+

If I have time later I will try installing the new dev version.

Edit: Octoprint version info

[schorsch3000]

I had no problems using DLP on a anet board running marlin 1 for at least 24 print hours (just to nail it down)

[enlight3d]

Layer shifts too here on a delta printer (FLSUN QQ-S) with 32bits motherboard. I'm running Klipper and printing at quite fast speeds (100-120mm/s).

DLP 1.19.1 Octoprint 1.4.0 on a Raspberry Pi 3B.

Since disabling the plugin, no more issues when starting the prints (had to restart the printer several times when the plugin was enabled to have a nice first layer, now it's no more needed... really strange) and no more shifts under raspberry high loads.

No issues on my other printer (Anet A8) with the plugin at the same version enabled. This Octoprint instance is running on a Synology NAS (DS218+) using Docker.

Seems like it really is linked to performance (Delta requiring lots of processing especially when running klipper which puts all calculations on the raspberry)

[Eddyg87]

The problem goes away on my Prusa MK3S when I reduce the travel speed from 180mm/s the to 150mm/s I have not played with acceleration rates yet.

[DrShats]

Hi, guys!

I see that many reporting of having no issues with DLP. I found that the problem (in my case stuttering, no layer shifts) is only appears when printer head is making many small movements. I think it has to be something with buffer overflow, because when I extend the buffer, it stutters less frequently. To test if DLP leads to stuttering I prepared a special g-code: no heating the bed or nozzle, all movements minimum 5mm above the surface of the bed, most important part - many short movements. You can make such test gcode easily, just slice any model with thin walls (2-3mm) with 1 thick walls and 100% infill at high speed, then in an editor replace all M140 M104 M109 M190 and E with ; thus commenting heating and extrusion out. Unfortunately I have to print a lot at the moment, and unable to test if newest DLP version is still causing problems. As soon I have time, I will test it and report back here, FYI I have Raspberry 3b+ with OctoPi and RAMPS+Mega2560

[Duke194]

Hello Guys,

I'm using DisplayLayerProgress since a few days and had no Issues so far.

Here some Details of my setup: Printer: Prusa MK3S Octoprint: 1.3.12 (Raspberry PI 3b+) DLP: 1.20.0

Using the original Printing profiles of Prusa (so no downscaled printer speed or smth like that). Just added the Layer indicators in the after_layer_change event.

And here a little proof of no layer shifts. Not tested any huge objects yet, but a report on that will follow as soon as I printed something larger.

Hope you can investigate where the problem of some guys came from. Lucky bug hunt, cheers.

[towlerg]

Perhaps there is a correlation Pi version used?

[mitchcecg]

I have both a pi 3b and a 3b+ both have had layer shifting on different printers

[thegarbz]

I can't help but notice that everyone reporting a problem is running Octoprint 1.4 (including myself) ... and a few people who have reported no issues are running 1.3.X

Resources wise. Load Averages while printing and while displaying realtime gcode updates on the web interface are 0.68, 0.50, 0.35. That doesn't really point to a resource issue. Also some reports of this from a Raspberry Pi 4 which is massively overpowered for this application and has dedicated USB controllers as well.

[DrShats]

I have same problem on 3B, 3B+ and 4(2GB) Confirm, I have Octoprint 1.4.0, I'm not sure, but looks like I had this problem before 1.4.0 was released And yes, disabling DLP eliminates stutters same as printing from SD with DLP activated

[OllisGit]

To get an better overview about the current situation I created a Wiki-Page. The page collects all of your feedback and give a good overview which "setup" works and which not.

https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/wiki/Issue124

Some informations were missing and maybe more details could also be helpful (e.g. Firmware), but my hope is, that I don't need to collect more informations.....and the Version 1.20.1dev will SOLVE ALL problems ;-)

[jerryfudd]

Only found out about this a few mins ago but had experienced a layer shift on my last print - had just presumed my build plate had moved but was no evidence of it having done so.

Creality Ender 3 Pro DisplayLayerProgress v1.20.0 Octoprint 1.4.0 OctoPi 0.17.0

[TobbeJ]

Interesting thread.

I have been using octoprint and DisplayLayerProgress for a long time and i have a prusa printer (mk3s with mmu2s) and so far have not had one single layer shift and i have had my printer for a bit over a year.

BUT the way i connect to the printer is a bit different, i had a ton of usb issues so i gave up on the usb port completely and instead i have a ftdi usb to serial board connected to the port normally reserved for a pi zero to connect directly via pin header to the printer board.

So, i wonder if there is anyone at all in this thread having layer shifts that also use a pi zero connected via the pin header to the controller board. I suspect there is none but that's just a guess and maybe i just got lucky?

So perhaps this is some kind of communication issue?

[floridaservices]

MK25S Running Prusa firmware 1.9.0RC DisplayLayerProgress v.1.19 up until today Octoprint 1.4.0 Octopi 0.17.0

Random layer shifts on a print until I slowed the print down to 75%. It then completed successfully. I have updated to 1.20.0 this morning and am running a longer print at 100%. Will see if it completes successfully

[Tor-Adi]

Ender 3 Pro Pi 3B+ Octoprint 1.4.0 Octopi 0.17.0 OctoDash 1.4.1 DisplayLayerProgress v. 1.20 Slicer Cura 4.4.1

I have noticed that I'm not getting levelshifts but my Extruder stepper is making a strange noice as it would like to press more filament into the tube but is forced back a couple of stepps. Not always but several times during a small print. When disabeling DLP the extruder stepper is quiet as it was printing of an SD card. I have read all the comments about the issue with DLP and wonder if my expirience is why some environments are OK and some not. Is anybody else getting noicy Extruder stepper with DLP?

I'm a Norwegian and new to the 3D printing game so sorry for my English language and knowledge.

[spiff72]

Interesting thread.

I have been using octoprint and DisplayLayerProgress for a long time and i have a prusa printer (mk3s with mmu2s) and so far have not had one single layer shift and i have had my printer for a bit over a year.

BUT the way i connect to the printer is a bit different, i had a ton of usb issues so i gave up on the usb port completely and instead i have a ftdi usb to serial board connected to the port normally reserved for a pi zero to connect directly via pin header to the printer board.

So, i wonder if there is anyone at all in this thread having layer shifts that also use a pi zero connected via the pin header to the controller board. I suspect there is none but that's just a guess and maybe i just got lucky?

So perhaps this is some kind of communication issue?

I would love to hear more detail about your connection approach. I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint. Is there more detail on what you did available online somewhere? I am wondering if this helps to eliminate the bottleneck of the USB serial connection from the Pi to the printer?

[DrShats]

Interesting thread. I have been using octoprint and DisplayLayerProgress for a long time and i have a prusa printer (mk3s with mmu2s) and so far have not had one single layer shift and i have had my printer for a bit over a year. BUT the way i connect to the printer is a bit different, i had a ton of usb issues so i gave up on the usb port completely and instead i have a ftdi usb to serial board connected to the port normally reserved for a pi zero to connect directly via pin header to the printer board. So, i wonder if there is anyone at all in this thread having layer shifts that also use a pi zero connected via the pin header to the controller board. I suspect there is none but that's just a guess and maybe i just got lucky? So perhaps this is some kind of communication issue?

I would love to hear more detail about your connection approach. I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint. Is there more detail on what you did available online somewhere? I am wondering if this helps to eliminate the bottleneck of the USB serial connection from the Pi to the printer?

I think he is talking about straight serial connection. I use same approach for all my printers to eliminated mentioned USB bottle neck

[blacksurgeon]

To get an better overview about the current situation I created a Wiki-Page. The page collects all of your feedback and give a good overview which "setup" works and which not.

https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/wiki/Issue124

Some informations were missing and maybe more details could also be helpful (e.g. Firmware), but my hope is, that I don't need to collect more informations.....and the Version 1.20.1dev will SOLVE ALL problems ;-)

Here the Python Version. I'm not sure what Version OctoPrint uses because I used OctoPi.

pi@octopi:~ $ python -V
Python 2.7.16
pi@octopi:~ $ python3 -V
Python 3.7.3

[spiff72]

Interesting thread. I have been using octoprint and DisplayLayerProgress for a long time and i have a prusa printer (mk3s with mmu2s) and so far have not had one single layer shift and i have had my printer for a bit over a year. BUT the way i connect to the printer is a bit different, i had a ton of usb issues so i gave up on the usb port completely and instead i have a ftdi usb to serial board connected to the port normally reserved for a pi zero to connect directly via pin header to the printer board. So, i wonder if there is anyone at all in this thread having layer shifts that also use a pi zero connected via the pin header to the controller board. I suspect there is none but that's just a guess and maybe i just got lucky? So perhaps this is some kind of communication issue?

I would love to hear more detail about your connection approach. I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint. Is there more detail on what you did available online somewhere? I am wondering if this helps to eliminate the bottleneck of the USB serial connection from the Pi to the printer?

I think he is talking about straight serial connection. I use same approach for all my printers to eliminated mentioned USB bottle neck

Is there more info on this online? I was just googling "direct serial connection octoprint" and found this video: https://www.youtube.com/watch?v=Du0-Ka2srIg Seems like it might be a good reference if I can figure out where the connection points are on the MK3S...

And does this allow for a faster connection to the printer than using USB?

[DrShats]

Interesting thread. I have been using octoprint and DisplayLayerProgress for a long time and i have a prusa printer (mk3s with mmu2s) and so far have not had one single layer shift and i have had my printer for a bit over a year. BUT the way i connect to the printer is a bit different, i had a ton of usb issues so i gave up on the usb port completely and instead i have a ftdi usb to serial board connected to the port normally reserved for a pi zero to connect directly via pin header to the printer board. So, i wonder if there is anyone at all in this thread having layer shifts that also use a pi zero connected via the pin header to the controller board. I suspect there is none but that's just a guess and maybe i just got lucky? So perhaps this is some kind of communication issue?

I would love to hear more detail about your connection approach. I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint. Is there more detail on what you did available online somewhere? I am wondering if this helps to eliminate the bottleneck of the USB serial connection from the Pi to the printer?

I think he is talking about straight serial connection. I use same approach for all my printers to eliminated mentioned USB bottle neck

Is there more info on this online? I was just googling "direct serial connection octoprint" and found this video: https://www.youtube.com/watch?v=Du0-Ka2srIg Seems like it might be a good reference if I can figure out where the connection points are on the MK3S...

And does this allow for a faster connection to the printer than using USB?

I use MEGA+RAMPS and I found quite enough info in my language, eg http://tough-3f.ru/tag/klipper-by-uart/ Try checking it out, the process is fairly simple. If you are using 32b mainboard for your printer, it is even simplier! I'm not worried about connection speed, there is already enough speed, as I'm worried about eliminated infamous USB bottleneck. Connecting Raspberry to printer mainboard via UART is eliminating it. I'n not familiar with MK3S, but if it is based on Arduino Mega 2560 chip, connecting it to the Raspberry is the same as for RAMP, just other pins may be involved.

[cad435]

Hey! Question to all of you: Wich Firmware did you run? I had layershifts happen on Marlin 2.0.x to (exactly how it was described here, between 0.2 and 0.5mm), but blamed Marlin for it and downgraded to 1.9.x (wich solves the problem, no layershifts with the plugin...) I read a lot about prusa users on this issue, but i can't tell if their FW is based on 1.9.x or 2.0.x...

greetings cad435

Edit: Oh, I somehow did not see the compiled Wiki-Page, so here are my two tested setups:

Custom MendelFrame Machine, Octoprint 1.4.0 @ OrangePiZeroW with Python 2.7.16. DLP 1.19.1 Marlin Fimware 1.9.x-bugfix Works Marlin Firmware 2.0.x-bugfix Works not

[spiff72]

Interesting thread. I have been using octoprint and DisplayLayerProgress for a long time and i have a prusa printer (mk3s with mmu2s) and so far have not had one single layer shift and i have had my printer for a bit over a year. BUT the way i connect to the printer is a bit different, i had a ton of usb issues so i gave up on the usb port completely and instead i have a ftdi usb to serial board connected to the port normally reserved for a pi zero to connect directly via pin header to the printer board. So, i wonder if there is anyone at all in this thread having layer shifts that also use a pi zero connected via the pin header to the controller board. I suspect there is none but that's just a guess and maybe i just got lucky? So perhaps this is some kind of communication issue?

I would love to hear more detail about your connection approach. I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint. Is there more detail on what you did available online somewhere? I am wondering if this helps to eliminate the bottleneck of the USB serial connection from the Pi to the printer?

I think he is talking about straight serial connection. I use same approach for all my printers to eliminated mentioned USB bottle neck

Is there more info on this online? I was just googling "direct serial connection octoprint" and found this video: https://www.youtube.com/watch?v=Du0-Ka2srIg Seems like it might be a good reference if I can figure out where the connection points are on the MK3S... And does this allow for a faster connection to the printer than using USB?

I use MEGA+RAMPS and I found quite enough info in my language, eg http://tough-3f.ru/tag/klipper-by-uart/ Try checking it out, the process is fairly simple. If you are using 32b mainboard for your printer, it is even simplier! I'm not worried about connection speed, there is already enough speed, as I'm worried about eliminated infamous USB bottleneck. Connecting Raspberry to printer mainboard via UART is eliminating it. I'n not familiar with MK3S, but if it is based on Arduino Mega 2560 chip, connecting it to the Raspberry is the same as for RAMP, just other pins may be involved.

Thanks - I will look into some of these details. I know for sure that it is an 8-bit (not 32) controller board, but I don't know which one specifically. Since the board has a place to connect the Pi Zero, I am assuming it should be trivial to find where to connect the serial data lines.

[REKLOKI]

I was wondering why my prints all of the sudden had a major layer shift..... I had DLP and a few other plugins disabled, but turned DLP back on and it started to shift. It was baffling why it would start all of the sudden. I am going to disable it and see how it goes.

[radimsejk]

I disabled the DLP plugin and had multiple layer shifts in latest print right now. With no visible problem on video.

Video: https://www.twitch.tv/videos/600091683 Logs and Gcode downloaded from Octoprint: Link to Dropbox

Prusa MK3S 3.8.1 DisplayLayerProgress v1.20.0 Octoprint 1.4.0 OctoPi 0.17.0

[towlerg]

@spiff72

"I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint."

Do you have these problems with DLP disabled?

[spiff72]

@spiff72

"I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint."

Do you have these problems with DLP disabled?

I will run a print right now to check...

[spiff72]

@spiff72

"I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint."

Do you have these problems with DLP disabled?

Update to my earlier comment. I tried again with DLP enabled (ver 1.20.1.dev0), and I was getting the slow movements and stuttering.

Running the same print again with DLP disabled (after deleting it from Octoprint and resending the Gcode), and my initial impression is that it seems better. I am letting this one go for a bit to see if I notice anything.

There was one feature that was printing poorly previously with DLP enabled, and I am waiting to see how that feature turns out.

[Duke194]

Hello Guys,

I'm using DisplayLayerProgress since a few days and had no Issues so far.

Here some Details of my setup: Printer: Prusa MK3S Octoprint: 1.3.12 (Raspberry PI 3b+) DLP: 1.20.0

Using the original Printing profiles of Prusa (so no downscaled printer speed or smth like that). Just added the Layer indicators in the _after_layerchange event.

And here a little proof of no layer shifts. Not tested any huge objects yet, but a report on that will follow as soon as I printed something larger.

Hope you can investigate where the problem of some guys came from. Lucky bug hunt, cheers.

I'm running Prusa Firmware version 3.8.1. I've taken a quick look into the Marlin.h and Marlin_main.cpp files of the firmware package but could not identify it's version. But feel free to take a look here: prusa3d/Prusa-Firmware

[spiff72]

@spiff72 "I have been printing from SD card lately because of print quality issues (slow movements, stuttering, etc) when printing with Octoprint." Do you have these problems with DLP disabled?

Update to my earlier comment. I tried again with DLP enabled (ver 1.20.1.dev0), and I was getting the slow movements and stuttering.

Running the same print again with DLP disabled (after deleting it from Octoprint and resending the Gcode), and my initial impression is that it seems better. I am letting this one go for a bit to see if I notice anything.

There was one feature that was printing poorly previously with DLP enabled, and I am waiting to see how that feature turns out.

Well, the feature I said I wanted to keep an eye on printed rather poorly, but I think it is safe to say that the stuttering and slowness was 95% gone from the performance when DLP was enabled.

[DrShats]

Tested new 1.20.1dev. Still stutters. Attached the gcode I use to test it. It's a gcode, just remove .txt extension stutter_test.gcode.txt

[spiff72]

Tested new 1.20.1dev. Still stutters. Attached the gcode I use to test it. It's a gcode, just remove .txt extension stutter_test.gcode.txt

Curious - do you find the stuttering most noticeable on short quick movements (like small bits of infill or small radii)?

[DrShats]

Tested new 1.20.1dev. Still stutters. Attached the gcode I use to test it. It's a gcode, just remove .txt extension stutter_test.gcode.txt

Curious - do you find the stuttering most noticeable on short quick movements (like small bits of infill or small radii)?

Yes, that is why I made this specific g-code. As I wrote before, it has to do something with the buffer, because when I increase it, stattering becomes less frequent

[frd2002]

Hello Everybody, I would like to give you my feedback about version 1.20.0 on my setup (Raspberry Pi4/4GB Ram, running Octoprint 1.4.0). After my upgrade to latest version, I do NOT suffer from any layers Shifts anymore. It seems that changing from sync to async operandus was a game changer.

I 've made my comment to https://forum.prusaprinters.org/forum/original-prusa-i3-mk3s-mk3-user-mods-octoprint-enclosures-nozzles-.../octoprint-issues-layer-skipping-print-pausing/paged/2/#post-207840 already.

Of course, I will keep posting if my experience changes. Frd2002 - Printing on my Prusa i3mk3S.

[spiff72]

Another update here - just to rule out USB bottleneck, today I successfully connected my Pi3B+ to my MK3S via a direct serial connection. Unfortunately, I still get the stutters/pauses with DLP enabled (1.20.1.dev).

[xeddog]

I've been having a quality issue with my Ender 5 Plus. I have seen several references to "stuttering". In the attached photo, the three cylinders were printed on the same machine using the exact same gcode file. The first one on the left was printed using Octoprint with Display_Layer_Progress plugin installed and enabled. Each of the bumps you see is where the print head just stopped for a couple of seconds and then continued. It is NOT a change of layer or perimeter. The one in the middle was then printed again after disabling DLP plugin. Better, but still a few bumps here and there. The last one was printed directly from the SD card in the printer's display. No bumps. Let me know if I should take this to another forum or ???? Also, I tried 6 times to get the photo upright.

[OllisGit]

Thx @xeddog,

please add details about your setup: printer, fw, op, dlp, ...

[jerryfudd]

@OllisGit thanks for trying to get this sorted out, its really appreciated.

I posted earlier about having the issue but to be fair it was just once and the print before was fine - being around 20hr print I disabled DLP just a precaution (my reprint came out fine).

Is there a known problem STL we all could be printing to help eliminate some of the randomness in the data that is being collected? obviously in an ideal world something relatively quick and not heavy on filament but it is what it is...

[DrShats]

@OllisGit thanks for trying to get this sorted out, its really appreciated.

I posted earlier about having the issue but to be fair it was just once and the print before was fine - being around 20hr print I disabled DLP just a precaution (my reprint came out fine).

Is there a known problem STL we all could be printing to help eliminate some of the randomness in the data that is being collected? obviously in an ideal world something relatively quick and not heavy on filament but it is what it is...

As for me the problem appears in stutters during print. The head just stops moving for a second or two and then continues. I found this is more frequent during moves with high ammount of direction changes, eg infill of long but narrow areas. So I made a g-code (see above) to test it. This g-code is just sliced wide radius thin tall disc with 100% infill and 1 each wall bottom and top, 100mm/sec printing speed and 3000mm/sec2 acceleration. I disabled extrusion and heating to not to spoil filament (just replaced M104, M140, M109, M190 and E with ; commenting them out). I raised nozzle 5mm after homing but befor movements to avoid damaging printing surface I used. You can try using mine g-code or produce your own.

[xeddog]

Thx @xeddog,

please add details about your setup: printer, fw, op, dlp, ...

I had it on my list to include all that info, and then didn't look at it. Anyway, running Octopi 0.17.0 and DLP 1.20.0 running on a Pi3B+. Octoprint shows version 1.4.0. I know this doesn't make a difference, but the Pi is cabled to my Ethernet network and connected to the printer via short USB cable about 3' long. I also have several other plugins including DASHBOARD which depends on DLP for some of it's information.
The machine itself is a Ender 5 Plus running Marlin 2.0.5.3 firmware on an SKR Pro V1.1 controller (external EEPROM added too). Drivers are TMC2209 (BTT V1.2 UART) for X, Y, Z, and Z2. LV8279 drivers for E0 and E1 although E1 is not used at this time, and no cable is connected to the port. The extruder is a BMG direct drive clone from TriangleLabs. The control box has been moved outside of the frame which necessitated making longer cables for just about everything. Using this setup has yielded some very good quality prints until lately.

I also have a CR-10S running a 32-bit MKS SGEN L board with FYSETC 2208 drivers (UART), and a very similar firmware/software setup. It also has direct drive extruder, but a Titan Aero, and it also has mostly home made cables. I don't THINK it has this problem but I have to fix it to find out for sure. I'm getting thermal errors now and it just shuts down while heating.

[daavery]

this is a simple part that seems to trigger the problem:

https://www.prusaprinters.org/prints/30441-face-mask-nose-clip

[Foxies-CSTL]

Hi, Same problems at high speed (150mm / s) when I was printing COVID shields. AM8 Bear Pi 3B+ Octoprint 1.4.0 Octopi 0.17.0 DisplayLayerProgress v. 1.19.0 Slicer PruSlicer last Ramps1.4/Marlin 2.0.5

[floridaservices]

Prusa mk25s 1.9.0RC3 firmware Pi 3B+ Octoprint 1.4.0 Octopi 0.17.0 DisplayLayerProgress v. 1.19.1dev Slicer PruSlicer latest version

Ran another test print 100mm/s yesterday - skips on x axis with DLP enabled, skips do not occur when feedrate is slowed down to 70%. Skips do not occur when DLP is disabled.