"Probe triggered prior to movement" but probe is open

General Discussion
1

I recently had to change my probe to a high temp one because my old one wasn’t rated at pc temps. I accidentally ordered a PNP probe so I made it go to an NPN transistor with a pullup resistor on the input and it seemed to work. When I poll the probe with “QUERY_PROBE” I get “open”. After putting something metal right up against the probe I get “triggered”. I take the metal part away and I get “open” again so it seems to work.

However, when I tried to run g32, the home works and the printhead moves to the first position for QGL and then I get a “Probe triggered prior to movement” error.

The probe config:
[probe]

pin: !PA2
x_offset: 0
y_offset: 25.0
#z_offset: 0
speed: 10.0
samples: 3
samples_result: median
sample_retract_dist: 3.0
samples_tolerance: 0.006
samples_tolerance_retries: 3

2

forgot to include log
klippy (13).log (695.4 KB)

3

What type of bed do you have and does the probe trigger if you manually proximate the probe to the bed?

4

I have a spring steel PEI bed and yes, it does trigger. Before I started g32 I homed and slowly moved the printhead down until the nozzle was about 1mm from the bed and when I queried the probe it showed “triggered”. I moved it back up then it showed “open”.

But the printer isn’t even getting to that point. it just goes in the first xy point then throws the error, not moving down at all. I queried the probe right after and it said “open”.

5

Even if the head is at home position, the head moves a bit away from that point to do a new proper homing.

Sorry, was the wrong log…

6

Yes, the x and y are moving in the correct direction. This printer has been running for over a year. The only change I just made was the probe. It homes in x, y and z just fine, then it goes up and to the xy of the first probe position for the QGL, then gives the “Probe triggered prior to movement” error and stops.

7

Obviously the probe is too sensitive and the head needs a greater Z-hop prior to homing.

[safe_z_home]
home_xy_position:
#   A X, Y coordinate (e.g. 100, 100) where the Z homing should be
#   performed. This parameter must be provided.
#speed: 50.0
#   Speed at which the toolhead is moved to the safe Z home
#   coordinate. The default is 50 mm/s
#z_hop:
#   Distance (in mm) to lift the Z axis prior to homing. This is
#   applied to any homing command, even if it doesn't home the Z axis.
#   If the Z axis is already homed and the current Z position is less
#   than z_hop, then this will lift the head to a height of z_hop. If
#   the Z axis is not already homed the head is lifted by z_hop.
#   The default is to not implement Z hop.
#z_hop_speed: 15.0
#   Speed (in mm/s) at which the Z axis is lifted prior to homing. The
#   default is 15 mm/s.
#move_to_previous: False
#   When set to True, the X and Y axes are reset to their previous
#   positions after Z axis homing. The default is False.

Try a larger value for z_hop

8

Z_hop was at 30, I changed it to 100 and ran g32.
It homed, moved about 100mm up, then moved back down, then moved to the first position and gave the same error without moving down at all.
I don’t think the probe is too sensitive, the sense distance is only 3mm and it’s about 30mm away when it throws the error.
klippy (14).log (758.1 KB)

9

You may adapt that value here too:

[quad_gantry_level]
gantry_corners = 
	-60,-10
	410,420
points = 
	50,50
	50,350
	350,350
	350,50
speed = 100
horizontal_move_z = 30   #<-----------------
retries = 5
retry_tolerance = 0.0175
max_adjust = 18
1 Like
10

Try increasing horizontal_move_z: Configuration reference - Klipper documentation

1 Like
11

@Sineos : Chips - Cola :wink:

1 Like
12

I increased the horizontal_move_z from 30 to 100 and it still did mostly the same thing. It homed, went up 100mm, moved in xy to the first probe point, then just stopped and gave the error.

Just as I typed this I got a “triggered” from the probe query. I queried the probe 10 more times and 3 of them were triggered. I have too much noise. I am going to solder a 1k resistor in parallel with the 10k pullup resistor I have on there now and see if the noise goes away.

1 Like
13

The resistor was it. After I put a 1k in parallel, I ran the query about 30 times with the printhead away from the bed and all 30 times it read open. QGL worked after that.
Lesson learned: don’t use a resistor value too high as a pullup/pulldown resistor.
Also don’t order $200 dollar probes while high lol.

2 Likes
14

Could you explain you probe circuit? Ideally draw a circuit diagram?

You said you have a “PNP probe” that you “made it go to an NPN transistor with a pullup resistor on the input”. Now you have a 1k resistor in parallel to the 10k which you apparently had originally.

I don’t get a good idea what you’ve done here and I’d like to understand how things are wired.

15

I just made an ugly circuit in paint, let me know if you want any more detail. I just looked up the transistor I used and the input is only good for 20v so I should probably change that lol.

Voron probe transistor wiring

16

There is a definite problem with you circuit as well as a potential problem that you’re masking with the 1k resistor.

Definite problem: you’re not using an “NPN” transistor - that device name is used to indicate that a transistor is a bipolar device and not a MOSFET. What you are using is an N-Channel MOSFET which is a completely different beast.

I’m bringing this up because a bipolar transistor is current controlled device:

and a MOSFET is voltage controlled:

The base of a bipolar transistor allows current to flow through it and the gate of a MOSFET doesn’t. The gate of the mosfet is really the anode of a capacitor and this means that when the PNP output of your probe is turned off there is a charge (and associated voltage) left on the gate which means it doesn’t turn off (which is what I believe you were seeing) - although there may be some charge leakage over time.

What you should have is a pull down on the MOSFET’s gate which will bleed the charge when the PNP’s output is off - something like the circuit:

image
image1450×861 31.9 KB

Now, just as importantly, you haven’t indicated what controller board you are using and whether or not the input pin is pulled up on the board.

Most 3D printer controller inputs have a 4.7k to 100k pullup to 5V - your pull up on the MOSFET’s drain to 3.3V is going to cause an intermediate voltage on the pin you’ve marked as the “S” input (between 5V and 3.3V because you now have a voltage divider at the input pin). This is the “potential problem” I noted above.

Could I ask you to:

  1. Put a voltmeter on the “S” input and look at the voltage levels before and after the Z axis sensor is active. If I were to guess, I’d think the low voltage will be something above 0.5V and the high voltage will be around 4.0V.
  2. Remove the 1k resistor at look at the voltage levels before and after the Z axis sensor is active. I suspect you’ll see the low voltage will be around 2.5V. high should stay around 4.0V.
  3. Remove the 10k resistor between “S” and 3.3V and measure the voltage at the “S” input with the Z axis sensor active and inactive. You should see a low of around 0.3V and a high fo 5V. There is a good chance that the change in state takes a while to happen due to charge leakage although it is accelerated when you put the voltmeter probe on the line.
  4. Put in a 10k resistor between the transistor’s gate and ground. You should see a very crisp difference of around 0.3-0.5V for low and 5V for ‘high’ at the “S” input.
  5. If the voltage at the “S” input stays low, then put back the 10k resistor to 3.3V.

Let us know how it works or if you have any questions.

Sorry for the long reply.

1 Like