Issue with missed steps, incorrect positioning after collision

General Discussion
1

Basic Information:

Printer Model: flsun SR
MCU / Printerboard: Robin Nano v3.1 and raspberry pi 2b
[
klippy.log (39.5 KB)
] klippy.log

Describe your issue:

Hello everyone,

I have upgraded my flsun SR printer to Klipper with a Raspberry Pi. Overall, the result is good but I have a major issue with homing after a collision. If for some reason during a print a collision occurs and the steppers lose steps, in subsequent prints there remains a sort of memory of the lost steps with potentially disastrous consequences (scratched bed).
(The drivers are the original ones: TMC2209)

I conducted the following test:

1)Printer calibration, initially cold, while bed leveling and adjusting the z_offset setting the working temperature

  • Z_OFFSET_CALIBRATION

  • DELTA_CALIBRATION

  • ENDSTOPS_CALIBRATION (ENDSTOP_PHASE_CALIBRATE)

  • BED_LEVELING

  • Z_OFFSET ADJUST

  1. Verification of successful calibration with a test print: first layer test
  2. After homing, I perform a movement and manually block the printer’s effector causing the steppers to lose steps
  3. I perform a homing and repeat the test print

At this point, the positioning is incorrect, the print scratches on the bed and/or is lifted.
I believe I have only encountered this problem with Klipper, with Marlin (original) I don’t recall this issue.
I think it’s related to ENDSTOP_PHASE_CALIBRATE but it’s just an idea and after much research I wouldn’t know how to intervene anyway. Can you help me?

Thank you

2

Hello @fox88x !

[tmc2209 stepper_a]
uart_pin = PD5
run_current = 1.138
hold_current = 0.5
stealthchop_threshold = 999999

...

[tmc2209 stepper_b]
uart_pin = PD7
run_current = 1.138
hold_current = 0.5
stealthchop_threshold = 999999

...

[tmc2209 stepper_c]
uart_pin = PD4
run_current = 1.138
hold_current = 0.5
stealthchop_threshold = 999999

The hold_current is way too much off from the run_current.

It’s also recommended to go without hold_current.

https://www.klipper3d.org/TMC_Drivers.html#prefer-to-not-specify-a-hold_current

1 Like
3

Thanks for the support, I’ll test the changes soon. My doubt however remains, how is it possible that the lost steps remain in memory/survive even after homing. I would like to specify that homing is at the coordinate z=320 (approximately) while z=0 should be calculated from the position of the steppers and from the z_offset and delta calibration

4

Do you do a homing with G28 or do you just go to coordinate 0,0?

5

I doubt that the stated observations are related. A proper G28 touching all tower endstops (which is the only way to home a printer) will reset the printer’s coordinate system.

Any other behavior would be a systematic bug and since this is the first report of this kind, I would be rather surprised.

  • Might be macro related - lots of them doing a lot of saving stuff - did not check in detail - does it also happen without all these macros stuff?
  • Does it also happen when issuing a FIRMWARE_RESTART after provoking the lost steps?
  • Does it also happen when restarting Klipper after provoking the lost steps?
  • Does it also happen when skipping the endstop phase calibration?
6

Thank you, it will take me a while to test these things. Yesterday I just changed the heatbreak and calibrated it because with the previous print, I bent the heatbreak and scarred the bed. The idea came to me while observing that only after problematic prints, where issues such as layer shifting or failures occur, does this problem arise. In the second to last print, I observed the print and verified layer shifting caused by poorly printed PLA blob. With the last print, I actually crashed the nozzle onto the bed. I will monitor the old heatbreak and conduct tests.

7

homing with G28

8

I performed the tests, I am truly perplexed and frustrated! If I run a test print without filament and with only a few G-code instructions (a simple spiral from the center with just one layer), the issue does not arise with or without FIRMWARE_RESET. I then carried out 2 real prints (the classic 3DBenchy and flow test1 from Orcaslicer) with very poor results. I repeated the 3DBenchy print while observing, and the nozzle scrapes on the bed.

So, I thought maybe the bed had risen, but I checked the screws of the 3 bed support brackets, and they are tightly secured. I verified that the z_offset of Klipper has not changed since the last print, and indeed, it is constant. I then raised the z_offset to +z=1.5 and repeated the 3DBenchy print, but the tool still scrapes.

In the Flsun, the pulleys should be keyed to the steppers and are not easily inspectable. I will try to conduct a more thorough examination of them. This is the last idea I have left.

9

Check if your pulleys are well holding a motor shafts. Once I did get similar conditions after I had a collision - one of pulley become lose and was giving slack, it wasn’t huge one like 10 degree - but it was driving me nuts :slight_smile:

To test it - you need to activate your motors and while toolhead is stationary - try to wiggle the belts - if there is a slack - you will fill it.

10

The pulleys are locked by pressure onto the stepper motors, and if I manually block the carriage’s movement, the stepper motors skip steps, and I can’t understand if there is relative slippage in the pulleys. So I disassembled the stepper motors and made a scratch on the shaft and pulley to check for any slippage between the two.
I have another issue. Thinking it might be the TMC drivers, I replaced them with others I already had, the TMC2209 from BTT. The printer also comes with stock TMC2209, so I thought they would work fine, but I was wrong. The BTT TMC drivers have 2 pins that are missing in the original printer’s drivers, but the pins defined in the printer.cfg file (enable, dir, and step) are the same. When I mount the BTT drivers, sometimes a simple homing works, while other times everything gets stuck and vibrates a lot. What am I doing wrong?
pinout

11

Most probably you need to manually tune the current thru regulation pot in that driver.

12

These are just the Diag pins that would be relevant for sensorless homing. It is not related to the discussed issues.

For me, it looks like hardware issues, e.g. with the wiring or the stepper itself or the points @gaolst mentioned.

If the stepper is only jittering / vibrating but not turning, then usually you have mixed the phases and this needs to be corrected.

13

I will study the current regulation. However, I would like to make sure that the connection and calibration are correct. What do you mean by mixing phases? I simply replaced the original TMC2209 drivers with those (TMC2209) from BTT without any wiring modifications. I found some guides for the Flsun QQ with Robin Nano 1.2 (I have a Flsun SR and Robin Nano 3.1) that connect the UART pins to the Wi-Fi module. This doesn’t concern my printer, correct? Is my configuration the same as the original drivers?

########################################

X Stepper Motor & Driver Settings

########################################

[stepper_a]

step_pin: PE3

dir_pin: PE2

enable_pin: !PE4

microsteps: 16

rotation_distance: 40

endstop_pin: PA15

homing_speed: 50

homing_retract_dist: 5.0

homing_retract_speed: 10

#angle: 210

#position_endstop: 336

#arm_length = 315

[tmc2209 stepper_a]

uart_pin: PD5

run_current: 1.138

#hold_current: 0.5

stealthchop_threshold: 999999

########################################

Y Stepper Motor & Driver Settings

########################################

[stepper_b]

step_pin: PE0

dir_pin: PB9

enable_pin: !PE1

microsteps: 16

rotation_distance: 40

endstop_pin: PD2

#angle: 330

[tmc2209 stepper_b]

uart_pin: PD7

run_current: 1.138

#hold_current: 0.5

stealthchop_threshold: 999999

########################################

Z Stepper Motor & Driver Settings

########################################

[stepper_c]

step_pin: PB5

dir_pin: PB4

enable_pin: !PB8

microsteps: 16

rotation_distance: 40

endstop_pin: PC4

#angle: 90

[tmc2209 stepper_c]

uart_pin: PD4

run_current: 1.138

#hold_current: 0.5

stealthchop_threshold: 999999

https://www.angelrojasjr.com/2021/09/25/upgrading-flsun-qq-s-pro-to-tmc2209/