Trident raises bed in wrong direction on Z home, causing crash

[MiniMook]

Hello,

I built a new Trident from an LDO kit, and I was running into an issue migrating to Klicky.

When I comment out the safe_z_home section in the LDO-provided config and migrate to Klicky, following the instructions laid out at https://github.com/jlas1/Klicky-Probe/blob/main/Printers/Voron/v1.8_v2.4_Legacy_Trident/README.md , the bed direction switches when first running G28 for X, Y, and Z. This is the step where the bed should lower by about 25mm to give the nozzle and probe room to move. Of course, since the printer homes X first, Klicky doesn't bother attaching the probe at this point.

Instead, the bed moves up (as in the Z-height decreases) instead of moving down. This only happens with my Klicky configuration, that is, disabling Klicky and going back to the old config moves the bed in the correct direction. If the bed is already greater than 25mm away from the nozzle, then there are no issues, the bed moves up but stays away from the printhead, then X, Y, and Z home properly. Klicky even attaches and docks properly as well, since I calibrated everything else. Once Klicky is attached, I can run the z tilt adjust macros and move the axes manually and all of that works just fine. Therefore I do not believe this to be a motor wiring issue.

I've narrowed the issue to https://github.com/jlas1/Klicky-Probe/blob/main/Klipper_macros/klicky-macros.cfg#L663 which is the line that runs the command causing my problem.

Could someone help me figure out what is going on here, and maybe fix the issue?

[MiniMook]

This issue was resolved through the klicky config items:

variable_safe_z:                25    # Minimum Z for attach/dock and homing functions
# if true it will move the bed away from the nozzle when Z is not homed
variable_enable_z_hop:        True    # set this to false for beds that fall significantly under gravity (almost to Z max)

I needed to set variable_enable_z_hop to true to get the correct direction of motion. The README.md file at https://github.com/jlas1/Klicky-Probe/tree/main/Printers/Voron/v1.8_v2.4_Legacy_Trident may need updating, because for this line it says:

variable_enable_z_hop:          CHECK_COMMENT  # True on the v2.4, False on v1.8, Trident and Legacy

[FlyingT]

Same issue, Fysect Kit wondered why I should disable it but followed the instructions provided since why would they be wrong Result: https://ibb.co/nmHWgHK

Obviously I see this AFTER destroying my bed and finding the same solution myself ... :( @jlas1 please look into this, the default behavior is killing printbets atm

[julianschill]

I think I narrowed down the problem: Assuming enable_z_hop is False and safe_z is set to 25:

Here: https://github.com/jlas1/Klicky-Probe/blob/8290f00a6605a0904dd56109a5e595617daae02b/Klipper_macros/klicky-macros.cfg#L646-L647 kinematic_position gets set to 25 and safe_z_home to 0.

Here: https://github.com/jlas1/Klicky-Probe/blob/8290f00a6605a0904dd56109a5e595617daae02b/Klipper_macros/klicky-macros.cfg#L657 The current position gets set to Z=25

And here: https://github.com/jlas1/Klicky-Probe/blob/8290f00a6605a0904dd56109a5e595617daae02b/Klipper_macros/klicky-macros.cfg#L663

A G0 Z0 gets executed, which moves the nozzle 25mm towards the bed.

[MiniMook]

The current position gets set to Z=25

Sounds like that is incorrect, I think when no axes are homed, the kinematic position should be assumed to be Z=0 so that there is no possibility of moving the bed upwards.

the only situation in which this would be bad is if the real Z is >= 275mm and adding 25mm of travel would cause a crash towards the bottom of the chamber.

[jlas1]

that's interesting, let me have a look,that's not supposed to happen.

On Sun, 19 Feb 2023, 17:04 Julian Schill, @.***> wrote:

I think I narrowed down the problem: Assuming enable_z_hop is False and safe_z is set to 25:

Here: https://github.com/jlas1/Klicky-Probe/blob/8290f00a6605a0904dd56109a5e595617daae02b/Klipper_macros/klicky-macros.cfg#L646-L647 kinematic_position gets set to 25 and safe_z_home to 0.

Here:

https://github.com/jlas1/Klicky-Probe/blob/8290f00a6605a0904dd56109a5e595617daae02b/Klipper_macros/klicky-macros.cfg#L657 The current position gets set to Z=25

And here:

https://github.com/jlas1/Klicky-Probe/blob/8290f00a6605a0904dd56109a5e595617daae02b/Klipper_macros/klicky-macros.cfg#L663

A G0 Z0 gets executed, which moves the nozzle 25mm towards the bed.

— Reply to this email directly, view it on GitHub https://github.com/jlas1/Klicky-Probe/issues/184#issuecomment-1436039733, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD7HHCRDFUPTTKHKNATAVKDWYJHCXANCNFSM6AAAAAAUVXVXSU . You are receiving this because you were mentioned.Message ID: @.***>

[FlyingT]

The current position gets set to Z=25

Sounds like that is incorrect, I think when no axes are homed, the kinematic position should be assumed to be Z=0 so that there is no possibility of moving the bed upwards.

the only situation in which this would be bad is if the real Z is >= 275mm and adding 25mm of travel would cause a crash towards the bottom of the chamber.

Small note: All "default" Trident, independend of bed size, have A Z of 250 not 300

[btoconnor]

Very new to klipper and klicky, but I just ran into this issue as well. The comment around the code in question claims On the first G28 after motors losing power, moves the Z to safe_z distance, if z_hop is enabled. I had variable_enable_z_hop to False and I'm not using klicky as an end stop - I was surprised to see that the klicky macro would make movements on z in any direction in this scenario. I feel like the command G0 Z{safe_z} F{z_drop_feedrate} on L663 should be gated by enable z hop and/or klicky being a virtual end stop? I'd prefer the z axis to not move at all unless it's homed by the z endstop switch.

[srberard]

I have a v1.8. I too had to set the variable_enable_z_hop to true to get the correct direction of motion. The code appears to function properly, this is just a documentation bug IMHO. Once set to true, everything works as it should.

[ComradeHappy]

I had this issue too. Setting varaible_enable_z_hop to true did not work for me. This cfg file seems to work. Once more testing is done it will be uploaded.

Thanks @jlas1

klicky-macros.cfg.zip