CORE One layer shifts

Introduction

For CORE One, PrusaSlicer configs specify maximum feedrate of 350 mm/s and maximum acceleration of 7000 mm/s^2. Sadly, my printer is sometimes failing to print correctly at those speeds, creating layer shifts: one of the g-code commands does not succeed in moving the printhead to specified coordinates, but there's no closed loop feedback, so the firmware does not realize that - and continues the print at a wrong location relative to what was already printed.

This page is what I have figured out so far. Unfortunately I have fiddled with the printer quite a bit, so by now it's hard for me to say if this is the issue with the printer in general or I have messed something up with mine in particular.

Likely contributing factors

My current hypothesis is that the shifts tend to happen during sequences of tiny moves along curved path. But I've no idea why specifically is it problematic, nor how to properly fix it.

“Avoid crossing perimeters”

Many people have reported that “Avoid crossing perimeters” feature is causing such shifts: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4573

This feature does tend to generate sequences of tiny moves, especially for models with a lot of circular/curved perimeters.

Input Shaper

I initially reported that disabling Input Shaper has resolved the issue for me: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4732

Disabling it seems to marginally increase speed/acceleration at which a given move can be performed successfully. But that comes with increased ringing artifacts.

“Arc fitting”

“Arc fitting” feature is also reported to be causing shifts: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4737

I have not investigated this in detail yet, but in a few attempted prints switching it either way didn't seem to make a difference. It still might be related though, but contributing less than other factors in my particular case.

Attached files

Quick note before proceeding: if you decide to try these files on your printer - ensure that your belt tension is properly tuned first, and please post your results in comments, noting if you have a factory-assembled printer (and if you have replaced or even just disassembled any part of the CoreXY assembly) or assembled by you.

*.gcode

Attached g-code files are not complete prints, running them on their own is not very useful. They are just small snippets that I have seen failing (as in the printer performing the move incorrectly and the printhead ending up at the wrong spot).

specimen*.zip

These contain actually useful g-code files generated using the snippets described above. Each file repeats a corresponding snippet 500 times, and then runs the printhead across all four corners of the print area: if any shifts have occurred - it will loudly crash into at least one of the sides. Archives contain files for different combinations of feed rates and maximum acceleration values.

scripts.zip

Shell scripts used to generate the above g-code files. 

Specimens 1 and 2

These are extracted from actual print files I've got with PrusaSlicer. Both happen to be travel moves generated by “Avoid crossing perimeters” feature. I've added 50mm to all Z coordinates to remove any risk of damaging the print bed.

Specimen 2 in particular has been giving me trouble with settings as low as the feedrate of 250 mm/s and max acceleration of 3000 mm/s^2.

Specimen 3

This one is artificially generated: a walk around a half- circle in a tiny linear segments.