No trigger on z after full movement

[Laserbea4k43]

Hello,
I'm trying tap for the first time, my gantry is pretty high and when I home, Tap goes to the center for the bed, but does not touch the plate before stating:
No trigger on z after full movement
What setting did I miss in my configs?

[stepper_z]
step_pin: PF11
dir_pin: PG3
enable_pin: !PG5
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16
endstop_pin: probe:z_virtual_endstop
position_min: -10
homing_speed: 8
second_homing_speed: 3
homing_retract_dist: 3

 

[Indeed]

This is in the config file, [stepper_z] section:
position_max: 340
position_min: -10

In this case a "full movement" would be 350mm (position_max - position_min).

Maybe you started homing with the gantry higher than 350mm from the bed?

On my 2.4, built from an ordinary formbot kit, I measured 360 mm from nozzle tip to bed, with the gantry as high as I could get it.

To find your position_max, move the gantry by hand (with motors off) as high as you can get it, then measure the distance from the nozzle tip to the bed.
Maybe shave a millimeter off of the measured value, to avoid running into the frame by mistake later on.
I measured 360 and then set my position_max to 358.


EDIT, I forgot to mention:
***** Watch out so you don't go above the linear rails! *****
On my machine (formbot kit) it was quite possible to lift the gantry so high that the carriages would go a bit higher than the linear rails.
Not high enough to fall of completely, but enough to make me worry about bearing balls (ball bearings? ) falling out.
I had to mount physical endstops above all four Z rails to avoid going too high.
Nothing fancy, just something to stop the carriages.
In my case just a screw on a T-nut, screwed in as far as it would go, with the screw long enough to hit the carriage.

 

[Laserbea4k43]

I had to turn the printer off and move the gantry down. I was able to home since then. Hopefully this won't be a problem in the future.

 

[claudermilk]

In your other thread you mentioned using UnTap. I am seeing the same error intermittently on my UnTap. I can home consistently right now, and got it to run z_tilt_adjust ok (got the tolerance error mentioned in the other thread a lot). I had to shift my probe points to get the nozzle where the Klicky prob used to hit and that eliminated the no trigger error there. However, when running a test bed mesh, I am still getting this error on occasion. Not sure why.

 

[Laserbea4k43]

In your other thread you mentioned using UnTap. I am seeing the same error intermittently on my UnTap. I can home consistently right now, and got it to run z_tilt_adjust ok (got the tolerance error mentioned in the other thread a lot). I had to shift my probe points to get the nozzle where the Klicky prob used to hit and that eliminated the no trigger error there. However, when running a test bed mesh, I am still getting this error on occasion. Not sure why.

I'm guessing z_tilt_adjust is a parameter relevant to tridents? I imagine it's similar to a quad_gantry_level, where my samples are wildly inconsistent.
I've ordered a Tap kit, with the optical sensor. Hopefully that'll solve my problems, but I wouldn't mind troubleshooting until it gets here, for documentation-sake.

 

[claudermilk]

Yes, z_tilt_adjust is the same purpose for Tridents as QGL for V2: get the bed level. Sometimes I get the error, other times it cycles many (many) times before it's happy--even after having run before and no Z moves other than homing or probing in between.

I now have the parts to go back to optical, so I'm trying that next.

 

[Laserbea4k43]

Optical Tap?
-edit-
of course. Cool