Probe_Stow does not retract pin on SKR Pico

[nhusby]

When I turn the printer on, the probe will deploy and retract properly, but after the probe deploys for homing, it doesn't retract, it just stays out. I have to manually force it back in.

I tried manually entering commands in the console. Probe_Deploy works fine, but Probe_Stow has no effect, and neither does SET_PIN PIN=probe_enable VALUE=0.

I'm using the MicroProbe V2 with Klipper on an SKR Pico.

MicroProbe.conf

[output_pin probe_enable]
pin: gpio29 # The control IO pin 
value: 0 # Probe default retracted

# Probe deploy command
[gcode_macro Probe_Deploy] 
gcode:
  SET_PIN PIN=probe_enable VALUE=1

# Probe stow command
[gcode_macro Probe_Stow] 
gcode:
  SET_PIN PIN=probe_enable VALUE=0 

[probe]
pin: ^!gpio22 # The detection IO, ^ means high-level triggered, V2 should be ^! means low-level triggered.
deactivate_on_each_sample: False
x_offset: -33.0 # Actual installed offset of MicroProbe 
y_offset: -9.0 # Actual installed offset of MicroProbe 
#z_offset: 0.0 # Actual installed offset of MicroProbe 
speed: 5.0
activate_gcode:
  Probe_Deploy
  G4 P500 # Allow 500 milliseconds for the probe to deploy 
deactivate_gcode:
  Probe_Stow

[nhusby]

I just remembered that after a while the pin does eventually retract if it sits for a while, like if it's waiting a long time for the bed to heat to 105c.

Does gpio29 need a pulldown resistor or something?

How would I configure that in klipper, and could that hurt anything?

[nolmeijer]

Did you find a proper solution for this issue. I have the exact same issue on my SKR mini E3 V3.

[designnc]

I have the same problem, were you able to fix it or is it a faulty probe?

[nolmeijer]

I have the same problem, were you able to fix it or is it a faulty probe?

It appeared the length of the cable was the issue for me since I increased the length of the cable. I think this is because the pull up signal was too weak or interference was the problem.

Using the original (long version) of the cable fixed it so that my probe properly responded to the stow command.

[designnc]

I have the same problem, were you able to fix it or is it a faulty probe?

It appeared the length of the cable was the issue for me since I increased the length of the cable. I think this is because the pull up signal was too weak or interference was the problem.

Using the original (long version) of the cable fixed it so that my probe properly responded to the stow command.

I will check it, since I also had to extend the cable, since the length was not enough to reach my motherboard

[designnc]

I have the same problem, were you able to fix it or is it a faulty probe?

It appeared the length of the cable was the issue for me since I increased the length of the cable. I think this is because the pull up signal was too weak or interference was the problem.

Using the original (long version) of the cable fixed it so that my probe properly responded to the stow command.

That was it! Thanks!!! I guess I'll have to use a resistor or wait for my CanBus to arrive and use the short wire. Thank you very much, appreciated!!!

[nolmeijer]

I have the same problem, were you able to fix it or is it a faulty probe?

It appeared the length of the cable was the issue for me since I increased the length of the cable. I think this is because the pull up signal was too weak or interference was the problem. Using the original (long version) of the cable fixed it so that my probe properly responded to the stow command.

That was it! Thanks!!! I guess I'll have to use a resistor or wait for my CanBus to arrive and use the short wire. Thank you very much, appreciated!!!

You're welcome :)

[ThunderClap86]

Is there a viable option that doesn't use the original length wire? I am using a Voron and the wire doesn't reach the MCU with the wire it came with. Having the same symptoms, confirmed to "fix" the problem with the original wire. Just can't mount it to the tool head now.

UPDATE:

So I actually bought two examples of the V2 micro probe from the Ali sale. The second one tolerates the longer Voron wiring, the first was more picky. No settings changes. Seems some examples dont like the long wire and will not tolerate it.

[designnc]

Is there a viable option that doesn't use the original length wire? I am using a Voron and the wire doesn't reach the MCU with the wire it came with. Having the same symptoms, confirmed to "fix" the problem with the original wire. Just can't mount it to the tool head now.

UPDATE:

So I actually bought two examples of the V2 micro probe from the Ali sale. The second one tolerates the longer Voron wiring, the first was more picky. No settings changes. Seems some examples dont like the long wire and will not tolerate it.

My problem was solved by soldering the extension wires well, at first I used pins, and it didn't work as it should, the strange thing is that Cr-touch had no problems that way, but I think Microprobe is more picky.

[nhusby]

No, I never properly solved this problem. I modified my gcode to use the edge of the print bed to force the probe into the retracted position.

[JdeV987]

This is how I got mine to work: All of below must be in printer.cfg

[output_pin probe_enable]
pin: gpio29                                # The control IO pin 
value: 0                                   # Probe default retracted

# Probe deploy command
[gcode_macro Probe_Deploy] 
gcode:
    SET_PIN PIN=probe_enable VALUE=1

# Probe stow command
[gcode_macro Probe_Stow] 
gcode:
    SET_PIN PIN=probe_enable VALUE=0 


[probe]
# You need to use the z- stop connection for the MicroProbe connection with the black and white wires. 

pin: ^!gpio25                         # The detection IO
deactivate_on_each_sample: False
x_offset: 0.0                         # Actual installed offset of MicroProbe 
y_offset: 0.0                         # Actual installed offset of MicroProbe 
z_offset: 0.0                         # Actual installed offset of MicroProbe 
speed: 10.0

activate_gcode:
       Probe_Deploy
       G4 P500                        # Allow 500 milliseconds for the probe to deploy 
deactivate_gcode:
       Probe_Stow


[stepper_z]
# ? to be replaced by your own values
step_pin: gpio19
dir_pin:  !gpio28                    # You may or may not need to invert the signal with a !  (depending on your Z-motor direction.)
enable_pin: !gpio2
endstop_pin: probe:z_virtual_endstop

microsteps: ?
rotation_distance: ?       
position_min: ?
position_max:  ?
homing_retract_dist: ?
homing_retract_speed: ?
homing_speed: ?
second_homing_speed: ?

[MrFanfo]

just to give my two cents here, had the same issue on an skr pico, it wouldn't stow on it's own, sometimes it would stow after a while, deploying was ok, but stopped working when i sent the stow command, this by using the stock wires, both long and short, i also got a new microprobe just to check if the old one was defective, same results, i managed to get it working by wiring the servo part to the raspberry pi pins directly, and updating the pin reference in order to reference a gpio of the pi. works reliably now.