Layer Shift when using Klipper

General Discussion
21

I would not rely on the fact that these values are interchangeable between Marlin and Klipper.
delta_radius, angle, and arm_length must be calibrated via the instructions provided in the documentation. When this is done properly they will automatically be moved from your manually edited config into the

When comparing the delta calibrating result from Klipper with those from marlin, they are almost the same, only difference I found was the tower angle, they are quite different.
But you are right, me to prefer to use the values I’ve got from calibration, I hope to help myself find errors by comparing with the values I’ve got from Marlin.

Your stepper moves the belt with a pulley attached to its shaft. A pulley slipping on the shaft will cause layer shifts. If your configuration in Klipper were to use higher accelerations, it can slip the pulleys while they may not slip in Marlin. I am not suggesting this is a root cause, just one possibility.

When observing the printer during a print I couldn’t notice any slipping, even when printing with low speed and acceleration the problem persist. But ill keep an eye on it.

Your log shows that your [tmc2209] sections do not define sense_resistor value. If your step sticks sense resistors are not the default 0.110 Ohm then you are pushing incorrect current through your steppers. This is to my earlier point.

I revisited the TMC dokumentation and somehow overseen it, my TMC 2209 has the default 0.110 Ohm, should I still add sense_resistor: 0.110 to my [tmc2209] section?

22

It’s up to you. I would for completeness, but that’s me.

23

OK, I redid carefully all calibrations according to the provided Klipper Documentation.
I double and triple checked all values I’m using and did more research, and I am confident to say that it’s not a mechanical, electrical or delta value issue.
I did a test print with stelathchop and interpolation disabled to reduce the chances of layer shifts, but no luck.

I did few reinstalls, I tried KIAUH but weirdly after installing klipperscreen using the tool my display had no touch functionality, also when using KIAUH to get my
serial port it is a diffrent one from using the ‘ls /dev/serial/by-id/*’ command.
Also, I never managed to get a working connection to the board when using KIAUH.
My current installation is using MainsailOS provided inside Raspberry Pi Imager, and installing klipperscreen the manual way, only this way I’ve got it working.

I found one post where someone had problems with inaccurate delta calibration measurements, and he found problems in the code of Klipper, but it was from 2017, so I don’t like to interpret too much into it, as already been said, there are many people using Klipper on deltas successful. He also says that the values for delta calibration between Klipper and Marlin are indeed interchangeable, the fundamental calculations of the delta kinematics are the same, and you have to provide the same values for the calculations to take place.
My values work in Marlin, when they don’t work in Klipper, then it’s not the values. My Delta radius or Rod length don’t change just because I changed the firmware. Also, the values I’ve got from Klipper after calibration matches the values I’ve got from Marlin after calibration.
The problem is Klipper, I’m not going to say again it being a fundamental problem in Klipper, but it certainly is not my printer mechanics or calibration values. Probably my printer.cfg is wrong, but I don’t know what I’m missing.

I read another post where someone had problems with Klipper using the BTT SKR 1.4 board, and when switching back to a SKR 1.3 the issues went away … but would be a long shot to buy a new board and I can’t find enough reports on the net about incompatibility with the BTT SKR 1.4.

What I still have in mind, the probe connector on my board for the BL Touch on p0.1 doesn’t have any functionality, when using Klipper. I tried a simple switch and configured a normal [probe], but nothing got read on that pin, no matter what I tried but without any changes, other than the pin assignment to p1.0, which is the PWRDET connector on my board and the BLTouch sensor become readable. I don’t know if it’s a problem using this pin, the values I’m getting seems to be accurate and repeatable. In Marlin, the probe pin p0.1 works without any issue, don’t know why the pin become dead under Klipper.

I’m going to try out Fluidd instead of Mainsail, but I don’t have any hope to fix the issue, at this point I’m just trying.
Here’s a fresh .log and .cfg:
klippy.log (3.0 MB)
printer.cfg (9.1 KB)

24

Behold!

IMG_20220810_230941
IMG_20220810_2309411920×1139 117 KB

Finally, I did it. So I was right about my .cfg being the culprit.
I took a look into yet another delta printer.cfg and changed / add the following:

  • under [stepper] I added angle
  • I added [gcode_arcs] resolution: 0.7
  • changed under [bltouch]
    • samples_result from average to median
    • samples from 1 to 2
    • sensor_pin from ^P1.0 (PWRDET) to ^P1.26 (EODET)

And I also switched to Fluidd, but that didn’t fix it, what I already expected, I’m going back to Mainsail, I like it more than Fluidd. What exactly was the reason for the layershifts, out of those changed I don’t know, going to find that out later, I guess it’s the added line angle, which btw isn’t listed in the Configuration reference under [Stepper]. Maybe it was the BLTouch, not the changed Pin assignment, but doing two samples and doing median. And the rest i honestly just added because it were in the printer.cfg I looked into.
Anyway, I couldn’t be happier to finally got it working. For those who want to take a look into my current config, here it is again:
printer.cfg (9.1 KB)

Final question … at least for now, is there anything I could or should improve in my config, any questionable lines i should take a look at, unneeded or missing, overall structure?
Inputshaping is on my list, have to reinstall it yet.

1 Like
25

These prints are PERFECT!

26

Glad that you worked it out. :+1:
Although no changes listed should be causing shifts :man_shrugging:

Some comments:

BLTouch

  • I use a SKR 1.4T in one of my printers too. P0.10 is working for me (dedicated probe pin)
  • BLTouch is known for botching the first probe. I would use at least 3 samples to get ride of the first one
  • This is what I’m using (genuine BLTouch 3.1):
[bltouch]
sensor_pin: ^P0.10
control_pin: P2.0
pin_move_time: 0.680
stow_on_each_sample: True
probe_with_touch_mode: False
speed: 5.0
samples: 4
samples_result: median

gcode_arcs

  • Generally I would not recommend this feature
  • Only advantage is that it reduces the amount of data to be transferred between your RPi and the MCU
  • Back in dark history it was needed to workaround a bottleneck in the serial interface, especially in Marlin. Klipper solved this long ago with the virtual_sdcard feature
  • Can introduce unwanted effects and reduces precision
27

Also the slicer must support it (or use arc welder in OctoPrint).

28

These prints are PERFECT!

Glad you like it :slight_smile:

Also the slicer must support it (or use arc welder in OctoPrint).

Thats what I thought too, but i had added it anyways

Generally I would not recommend this feature

and already removed it again :slight_smile:

Glad that you worked it out. :+1:
Although no changes listed should be causing shifts :man_shrugging:

I was trying now to find out what setting caused my layershifts, and I don’t know what to believe any more lol.
I removed or reversed one change after the other, to see what setting caused it. I know even have the printer.cfg from my original post loaded and printed a cube that’s completely fine …
I even retried my probe pin P0.1 and even that works now without any problems …

Yesterday I’ve printed, a cube with layershifts, then I did the changes and everything worked as intended, beside the .cfg i haven’t touched anything, and now I cant recreate my issue lol.

Magic, luck, planets lined up in a row, who knows maybe it is an unreliableOS … I’m just joking ok, it’s just a joke :wink:
Maybe it was the underlying Raspberry image … I dealt with Linux so many times and know how unreliable it can be … anyway, since everything is working as intended, I thank you guys for helping me :slight_smile:

1 Like
29

I use Arc Welder for the side effect of increasing smoothness on curves with models found on the internet that were exported with low resolution.
This improves smoothness, print speed (lowers the move junctions angles) and reduce resonances.

But note that klipper’s gcode_arcs doesn’t scale the segment length with the arc radius, so it suffer from flattened curves with small radius.

30

I’m not sure that having one approximation (low resolution) and adding another approximation (arc welding) on top is a good choice. Probably just increases the dimensional error already caused in the first approximation. In the end you cannot undo the lossy transformation that happened in the low res export.
Personally I would never choose this approach as I cannot see any benefits. YMMV