probe triggered prior to movement

[seene]

Hey,

I use nudge (https://github.com/zruncho3d/nudge/) and unfortunately I have a problem determining the nozzle position

Z works normally, but as soon as the nozzle triggers on X axis, I get the following error message: “probe triggered prior to movement”

I have also tried your troubleshooting without success. I am using an Idex printer with Hybrid CoreXY w/ Dual Carriage. I have already installed “Frans-Willem's Klipper PR”.

do you have any idea what could be causing this?

[VIN-y]

Have you checked if the Nudge can electrically closed consistently?

[seene]

yes, I forgot to mention that measuring Z works. As soon as the measurement for X runs, I get the error.

i have also made a gcode_button trigger macro. that also shows nicely that the sensor is triggered by the nozzle. (and then I get the error message)

[VIN-y]

Alright. Nothing really came to my mind of what could have cause you issue. So, let's try breaking this down further.

There are 4 components to the calibration probe: hardware assembly, electrical wiring, the .cfg file, and the underlying python code.

You said Z works normally. So I am assuming that, after initiated, the machine would pick up T0 and move to calibration probe pin position. Then it moved down until it triggered the probe. Then it starts the x measurement, which is where the error occur? --- If so. We can push the hardware-assembly and electrical-wiring to the back of the potential-problem queue for now. The next thing to go over is your calibrate-offsets.cfg file. That is not to say that the config is the problem, as it is just a list of numbers for your tool-head to move along.

Follow the logic above, maybe you the tip of your hotend touched the pin when it moving toward the starting position for the x calibration, which then trigger the error for safety.

So... what hotend are you using? can we see your config file? and, can you check on for the potential cause above?

[seacred]

I got the same issue. Z working fine. here is my calibrate_offsets.cfg:

[tools_calibrate] pin: ^PG10 travel_speed: 25 #100 # mms to travel sideways for XY probing spread: 3 # mms to travel down from top for XY probing lower_z: 0.5 # The speed (in mm/sec) to move tools down onto the probe speed: 30 #2.5 # The speed (in mm/sec) to retract between probes lift_speed: 4 # Z Lift after probing done, should be greater than any Z variance between tools final_lift_z: 4 sample_retract_dist: 5 #2 samples_tolerance: 0.05 samples: 2 samples_result: median # median, average Settings for nozzle probe calibration - optional.

probe: probe # name of the nozzle probe to use; comment out if using Nudge as Z probe

trigger_to_bottom_z: 9.25 # Was 0.25 # Offset from probe trigger to vertical motion bottoms out. decrease if the nozzle is too high, increase if too low.

Error-message: Probe triggered prior to movement Probe made contact at 150.700000,253.000000,9.001250

My Sensor Location should be in center at aroung 151, 253 I'm using Klicky too and this is my klicky-probe.cfg:

i got no second named_probe configured. I'd like to know why this is demanded if this is the cause of the issue

[VIN-y]

Oh! the Nudge is a NC switch. so try taking the ^ out from your pin config. I.E.:

[tools_calibrate]
pin: PG10
...

[seacred]

Oh! the Nudge is a NC switch. so try taking the ^ out from your pin config. I.E.:

[tools_calibrate]
pin: PG10
...

i did this before and changed it again. No difference.

[russiancatfood]

I'm having the same issue on VORON Phoenix. Gonna trying to methodically isolate the cause. Initial thought: end stop state isn't being updated by Klipper while the queue is active.

[russiancatfood]

Debugging out loud here. Here's what I dug up in the logs:

run_probe direction = z-
run_probe axis = 2, sense = -1
Probe made contact at 305.900000,608.700000,4.341875
run_probe direction = x+
run_probe axis = 0, sense = 1
Probe triggered prior to movement
Probe triggered prior to movement

[russiancatfood]

Added some debug into check_no_movement (the function that throws that error) and got this gem:

Stepper positions:
probe :: s:-756 t:173
probe :: s:-167 t:-167
Probe triggered prior to movement
Probe triggered prior to movement

It loops though StepperPositions and if any one start and trigger distance is the same it throws that error.

Here's a successful one from probing in Z direction:

Stepper positions:
probe :: s:-24977 t:-30336
probe :: s:-24977 t:-30336
probe :: s:-24977 t:-30336
probe :: s:-24977 t:-30336
Probe made contact at 305.900000,608.700000,4.325312

[a480615]

The exact same problem, no matter how I debug, it doesn't work

[russiancatfood]

Ok, I found the bug and it only effects X moves on Hybrid CoreXY printers (IDEX).

Basically, after triggering and endstop Klipper checks to make sure all motors involved in that endstop moved. If some didn’t, it throws that error. On an IDEX, when homing X, only one of the X motors will spin (hopefully). The other will stay put (hopefully). I’m gonna see if there’s a way to account for which steppers are currently active on a given axis and feed those into the endstop Wrapper.

Once I have a fix, I’ll make a PR

[russiancatfood]

Ok, found a solution to this particular edge case. We have to check for primary rail if dual_carriage object exists, and return only the x stepper for that rail.

PR: https://github.com/viesturz/klipper-toolchanger/pull/23

[russiancatfood]

It's not outright failing with my PR anymore, but I'm still seeing random probe trigger errors. Trying to root out any lingering bugs.

[seene]

I have made a few runs, so far no errors

[russiancatfood]

Well, I'm glad I'm encountering issues even with my PR installed. I think what I did was a bandaid and the fix needs to be handled a bit differently. Testing the fix now, hopefully the steppers will stop popping in and out of existence randomly.

[russiancatfood]

Ok, I’ve narrowed my persisting errors down to mechanical problems.

If @seene’s original problem is fixed I think we can close this out.

[seene]

so i did 10 or 15 tests yesterday and had no more problems. so i think from my side it can be marked as solved. Thanks for the help!!!