[BUG] Ghost layer shifts (at times) in X axis

[SteveKilling]

--> Printer type - MK3, PETG 1.75 filament. Machine recently cleaned and lubricated. Printer firmware version - 3.13.3

MMU upgrade - no MMU MMU upgrade firmware version

**SD card used for file transfer

Describe the bug 2 parts were printed of this large duct (5 hr 46 M) successfully. The 3rd part made a shift in the X axis of about 0.6mm at about 75% of the print. The 4th part had the same shift in the same location. This sounds like one of the challenges you were trying to fix in the latest release.

[update - the file from the SD card was read back into Slicer and it looked clean, no jogs or errors. For the 5th print, the file was re-sliced in PrusaSlicer, with 0.25mm for the first layer just to jog things a bit and the fill changed from Cubic to Gyroid. Print was successful. Still concerned about random success/failure rate without any changes from prints 1, 2, 3 and 4)

To Reproduce The first two prints were fine. The third and fourth had the error.

Expected behavior The first two prints were fine the last was expected to be the same

G-code I have attached the gcode file as a zip file.

Video and photo The photo shows the two successful prints on the left and the X axis shift on the right. The video is of the X-shift print.

https://github.com/prusa3d/Prusa-Firmware/assets/164060500/20f14836-52fd-44d3-81ba-eaa5585c9fac

Fog_Port_0.25mm_PETG_MK3_5h46m.zip

[3d-gussner]

@SteveKilling Sorry to hear that, did you contact tech support? Did the printer crashed on X or Y?

Is there a reason you choose the random seams, for me it looks like it generates way more travel moves than needed.

Can it be that the layer shift happened at the internal overhangs? While scrolling in Gcode viewer I see that these are printed first and may curl up and cool down before the other lines are printed.

Similar object with random seams vs aligned seams vs nearest seams

[SteveKilling]

3d-gussner, Thanks so much for your reply. I didn't contact tech support since I got the impression in the firmware release that this was the best way to make Prusa contact? No so?

The shift was in the X-axis and is just when the internal overhang shelf turns to vertical. It looks like it is at this point (image below) - just as the holes are beginning and the shelf is starting the vertical portion.

Thanks for the suggestion on the seam placement. I have always used random to keep form getting a vertical row of nubs on the model, but hadn't realized the time and motion implications.

If the internal overhanging mini-shelf curled up as you suggest, that might cause a collision that shifts X, but then it recovers and continues? Is that your thought?

Thanks for your help, Steve

[3d-gussner]

If the internal overhanging mini-shelf curled up as you suggest, that might cause a collision that shifts X, but then it recovers and continues? Is that your thought?

Big question is if a crash has been detected and the nozzle moved up and re-homed XY. Can you please check your Fail Stats to see if a X or Y crash has been reported. And also verify that crash detection is active.

It is difficult without any log files to troubleshoot these kind of things.

I just "assume/guess" from the PrusaSlicer Gcode Viewer that something may have curled up and may have caused a layer shift.

Detecting crashes isn't easy but the firmware tries hard to detect these as good as possible. But it is a balancing act between detecting and preventing false positives and may miss some edge scenarios.

With FW 3.13.3 the running currents are be back to previous versions and crash detection should work well

[3d-gussner]

If you print the same gcode again, please try to get some logfiles by connecting a PC or SBC via USB (before the print) maybe we can see, what is going on. Please modify your gcode for extended logging with an additional Line M155 S1 C7 after G28 W to report temp, pos and fan.

[Mec-mec]

I have same problem with Prusa MK3s+ (fw. 3.13.3), there are random layer shifts in stealth mode (seam position aligned).

[3d-gussner]

@Mec-mec In Stealth Mode the crash detection is disabled as it isn't reliable. Please verify with the PrusaSlicer Gcode viewer if the print has lot of travel moves. As you can see above I could find a lot of travel movements and tiny parts printed that may have curled up and caused the shifts.

[lordzurp]

Hi all

--- edit - 09/05/2024 --- seems fixeed, after lots of various FW flash, factory reset and some random black magic my printer is actualy fully functionnal again under 3.13.3 --- edit---

I had the "ghost layer shift" bug with 3.13.2 firmware, so I upgraded to 3.13.3 it was a bit better, but still have 50% of prints shifted. both X and Y crash detections without reason nor physical collision (I stay near the machine to inspect if there are a valid reason of collision detection)

somes collisions were detected, the head come back to zero-init and restart printing almost at the right place but seems some "collisions" or step shift on stepper didn't correctly aprehended

I tried to revert to 3.13.1 this week, and the few test prints I made seems to be perfect, as usual before upgrading to 3.13.x

Printer type - MK3S+, PETG 1.75 filament. Machine recently cleaned and lubricated (new linear bearings) Printer firmware version - 3.13.3

MMU upgrade - no MMU Octoprint 1.9.3, octopi 1.0 and octodash, connected with the UART port directly on the PI 3B+ PrusaSlicer up to date with prusament profiles

problem with multiple Gcode, even old ones who printed flawlessly

worked almost perfectly since 3K hours on meatpack custom firmware before going back on official firmware (3.13.2, for the meatpack support, not the better choice ^^ )

[Mec-mec]

@Mec-mec In Stealth Mode the crash detection is disabled as it isn't reliable. Please verify with the PrusaSlicer Gcode viewer if the print has lot of travel moves. As you can see above I could find a lot of travel movements and tiny parts printed that may have curled up and caused the shifts.

I rolled back to 3.12.1 firmware, there are no layer shifting.

[orbitinstasis]

@Mec-mec In Stealth Mode the crash detection is disabled as it isn't reliable. Please verify with the PrusaSlicer Gcode viewer if the print has lot of travel moves. As you can see above I could find a lot of travel movements and tiny parts printed that may have curled up and caused the shifts.

I rolled back to 3.12.1 firmware, there are no layer shifting.

What features do you miss by doing this ?

I'm having too many annoying Y axis phantom crashes.