Problem with SHAPER_CALIBRATE & TMC2209s with Sensorless Homing

Basic Information:

Printer Model: Custom CoreXY
MCU / Printerboard: Octopus V1.1 & FLY SHT42
klippy.log (3.2 MB)
canFly.cfg (3.1 KB)
printer.cfg (18.9 KB)

After running SHAPER_CALIBRATE followed by saving the results using SAVE_CONFIG Klipper returns the message when trying to print or home:

This happens all the time including after a FIRMWARE_RESTART and a power cycle.

What I did to isolate the problem was:

  1. Deleted the #*# [input_shaper] lines from printer.cfg
  2. Tried to home/another print after FIRMWARE_RESTART. No problems.
  3. Check the accelerometer status with ACCELEROMETER_QUERY and it received an error (Invalid adxl345 id (got xx vs e5))
  • Discovered that there were some components that were downlevel, updated and retested with getting the same error
  • Did a power cycle and retried ACCELEROMETER_QUERY and no problems
  • I donā€™t know how relevant this is to the problem but Iā€™m explaining everything that happened
  1. Reran SHAPER_CALIBRATE with SAVE_CONFG
  2. Tried to print and home have the same problem with Endstop x still triggered after retract
  3. This problem continues after FIRMWARE_RESTART and power cycle

This seems like a bug to me and Iā€™m guessing that during FIRMWARE_RESTART the code which sets the updated acceleration for the TMC2209ā€™s leaves them in a state where sensorless homing will not work.

You need to set retract_dist to 0 when using sensorless homing.

https://www.klipper3d.org/TMC_Drivers.html#configure-printercfg-for-sensorless-homing

Iā€™ve been running sensorless homing without homing_retract_dist: 0 without any problems. Why would it only come out after I do a SHAPER_CALIBRATE/SAVE_CONFIG?

Iā€™ll make the change (and comment out the `hold_currentā€™ specifications as set out in the documentation youā€™ve cited) and let you know how that goes.

Well. That failed spectacularly.

By adding the homing_retract_dist: 0 sensorless homing stopped working. The X axis just jerked once, the Y Axis moved to the far end of its travel (itā€™s supposed to go to the close end) and the machine jerked back and forth until I cut power.

Here are the changes I made (now commented out):
canFly.cfg (3.3 KB)
printer.cfg (19.7 KB)

@Sineos and @koconnor can you comment? Iā€™m not going to try homing_retract_dist: 0 again without your express direction.

@jakep_82 advice is fully correct. I have to admit that Iā€™m not a pro when it comes to sensorless homing. Tried it once for a while but I did not like it.
What I remember:

  • homing_retract_dist indeed needs to be set to 0 also and especially during the tuning process
  • With higher power steppers it makes sense to reduce run_current during homing, otherwise the touch down is a bit harsh. There is an example macro in the documentation.

Maybe some items to check:

  • Where do you have the ADXL connected? Directly on the printer board or on the RPi?
  • Invalid adxl345 id (got xx vs e5) typically is a wiring issue. My best experience is a Cat5e patch cable with less than 50 cm (I have found the MPUxxx on I2C much more forgiving than the ADXL)

I would suggest going through the entire document I linked to tune sensorless homing. I have no idea why youā€™re having issues, but you need to set retract_dist to zero to get reliable homing. I use this on all of my printers with no issues after following the guide in the docs and using the homing macros there.

@Sineos & @jakep_82

Sorry, thereā€™s some kind of problem here and Iā€™m loath to go forward until itā€™s understood.

Here is homing on the printer with the base printer.cfg and canFly.cfg (attached above) without any homing_retract_dist: 0 parameters:

Here it is with homing_retract_dist: 0 parameters in the stepper_x, stepper_y & stepper_z statements:

In this case, the X Axis homing is done correctly, but the Y Axis is going in the wrong direction and I have to intervene to end the operation and keep the printer head from colliding on the base.

I did not comment out the ā€œhold_currentā€ parameters as recommended on the page for the test in the video and I suspect thatā€™s why the movement isnā€™t as violent as it was the first time I made the changes. I do know about reducing run current for Stall Guard.

The thing that I suspect is the problem with the direction is that I invert one of the direction steppers for mechanical reasons why requires the ā€œDIRā€ value on [stepper_y] to be inverted. I would expect that this wouldnā€™t be a factor.

The ADXL345 is built into the FLY SHT42. I suspect the ā€˜Invalid adxl345 id (got xx vs e5)ā€™ is a state issue in the STM32F702 built into the FLY SHT42 which may be a software issue. In any case, I just did an ACCELEROMETER_QUERY and it returned without any issues.

Right now the accelerometer is a secondary issue to figuring out the problems with running sensorless homing and following the instructions here:

https://www.klipper3d.org/TMC_Drivers.html#configure-printercfg-for-sensorless-homing

Iā€™m probably a corner case, but this smells like a bug to me.

You need to use homing macros with sensorless homing. Those macros need to retract the carriage from the end of each axis before the next axis is homed. This is particularly important for corexy printers. If the carriage is pressed against the end of the X axis, it will put load on the Y stepper causing it to prematurely trigger the diag pin and signal the axis has been homed. This is what Iā€™m seeing in your videos.

1 Like

If you watch the first video closely, you will see that after doing the X and Y do retract before going onto the next step. What youā€™re saying is possible in the second video.

Regardless, Iā€™ll give the macro shown in TMC drivers - Klipper documentation a try tomorrow morning and report back.

Whatā€™s happening in the first video is also incorrect behavior, and itā€™s why the retract distance needs to be 0. It should be retracting and then doing a second home at half speed. What itā€™s actually doing is retracting and then immediately triggering when it starts the second home. This creates inaccurate homing, and it can also lead to an error indicating the endstop is still triggered after retract.

To add to @jakep_82 excellent advice: It is important to do the tuning already without any homing_retract_dist as it might be thrown off otherwise.

klippy.zip (2.7 MB)
printer.cfg (23.4 KB)
canFly.cfg (3.7 KB)

Well, two steps forwards and one back - Iā€™m hoping that you can help me get homing perfected.

I went through TMC drivers - Klipper documentation and went through everything step by step:

  1. Commenting out ā€œhold_currentā€ in the [tmc2209 stepper_#] statements
  2. Put in ā€œhoming_retract_dist: 0ā€ Statement in [stepper_x|y|z]
  3. Made sure tmc2209s are in StealthChop mode (stealthchop_threshold: 999999)
  4. Set homing_speed: 20 for both X and Y Axis (was 25 before)
  5. Found appropriate driver_SGTHRS value for X & Y running at 20

Things started to look good BUT doing homing was a bit iffy and before going on, I did a SHAPER_CALIBRATE with SAVE_CONFIG to see if that would work (as thatā€™s what started off this whole thing) and it seemed to run properly, printer.cfg was updated and rebooting was fine.

I also did an ACCELEROMETER_QUERY and no issues. For now, Iā€™m going to assume that the problem before was an artifact of the homing problems.

Going back to homing, as I said above, things were a bit iffy and I could not do a ā€œHome Allā€ so I tried to do a [homing_override] on the X axis with the sample macro provided in the documentation. This worked well, but it didnā€™t resolve the issues with the Y and Z axis (they basically wouldnā€™t work together and demanded that the ā€œpreviousā€ axis be homed).

I tried copying the [homing_override] for the Y axis and, no surprise, it took precedence over the X axis [homing_override]. As I have a non-functional printer, I decided to use the homing override for all three axes by modifying the original example code.

The [homing_override] code I cobbled together seems to work okay and I can run QUAD_GANTRY_LEVEL without any issues. You can see some experiments that I did in it to try different things that are commented out:

# XYZ Homing Override
[homing_override]
gcode:
    ### Lift Z Axis (just in case)
    ### G1 Z10 F100  <== Won't work except if everything is homed
    SET_KINEMATIC_POSITION Z=0
    G0 Z10 F600
#    G0 Y10 F600
#    G0 X10 F600
    {% set HOME_CUR = 0.700 %}
    {% set driver_config = printer.configfile.settings['tmc2209 stepper_x'] %}
    {% set RUN_CUR = driver_config.run_current %}
    # Set current for sensorless homing
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={HOME_CUR}
    # Pause to ensure driver stall flag is clear
    ### G4 P2000  <== Too long, especially with moving the Z Axis Up
    G4 P500
    # Home
    G28 X0
    # Move away
    G90
    G1 X200 F1200
    # Set current during print
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={RUN_CUR}
    ### Repeat the previous for the Y Axis
    {% set HOME_CUR = 0.700 %}
    {% set driver_config = printer.configfile.settings['tmc2209 stepper_y'] %}
    {% set RUN_CUR = driver_config.run_current %}
    # Set current for sensorless homing
    SET_TMC_CURRENT STEPPER=stepper_y CURRENT={HOME_CUR}
    # Pause to ensure driver stall flag is clear
    ### G4 P2000  <== Too long, especially with moving the Z Axis Up and doing X Calibration
    G4 P500
    # Home
    G28 Y0
    # Move away
    G90
    # G1 Y5 F1200
    ### Leave the carriage over the middle of the bed
    G1 X110 Y110 F1200
    # Set current during print
    SET_TMC_CURRENT STEPPER=stepper_y CURRENT={RUN_CUR}
    ### Home the Z Axis
    G28 Z0
    G0 Z10 F600
#   A list of G-Code commands to execute in place of G28 commands
#   found in the normal g-code input. See docs/Command_Templates.md
#   for G-Code format. If a G28 is contained in this list of commands
#   then it will invoke the normal homing procedure for the printer.
#   The commands listed here must home all axes. This parameter must
#   be provided.
axes: xyz

Now, I have two things I need to figure out:

  1. I said that home all [homing_override] works okay but there is one problem, the Z axis probing only takes place once, not twice (with the second time running slower). How can I add this to my home all [homing_override] code?
  2. Homing individual axes no longer seems to work (or at least X does, but Y and Z donā€™t because theyā€™re not getting confirmation that the previous axes are homed). How do I get these three buttons on Mainsail working properly again?

Thank you for your help - sorry I was somewhat obstinate before.

Seems to bring it together quite nicely. I never used sensorless homing on my corexy, just on a cartesian

I copied in the macros from the Voron site directly into my printer.cfg, pressed ā€œHome Allā€ and this was the result:

I am pretty upset right now although Iā€™m really glad I didnā€™t try these macros with my Voron (I was going to because I had a lot of problems with setting up the X/Y switches and it would be nice to simplify the wiring of the printer).

Iā€™ll go back to what I had before as they worked infinitely better (ie they donā€™t ruin a $30 PEI printing bed each time I run them) but the Z homing only took place once which didnā€™t provide acceptable accuracy for the Z Axis positioning.

What do you recommend I do next?

Darn, sorry to hear. :grimacing:

I still believe, this is the right approach. The only thing missing is the Z correction to make sure you have the needed head-room.
For the Vorons it is not needed since they home to their special Z-endstop design, which makes sure the nozzle is always away from the bed.

Itā€™s my own fault for trusting the code would be correct without checking it first but when it happened, I was very, very angry.

Iā€™ve been working on this for quite a while and have made some progress but I have an issue that I feel needs to be addressed (I believe it is the reason for the gantry crash early in this whole process) and a question about how to get the Z axis probing to execute twice.

This has been a lot more difficult than I believe it should be.

Letā€™s get this fixed. Please wait for my post.

1 Like