BLTouch probe not working

[gshorten]

I have a Kossel Delta, had the (original) BLTouch 3.1 working perfectly under Marlin. I have klipper working fine, the BLTouch probe goes up and down, but always reports "open". When I tried to do a DELTA_CALIBRATE I received this error: Send: DELTA_CALIBRATE Recv: !! Failed to home probe: Timeout during homing The pin deploys, color changes from red to clear, after the bltouch probe had moved a few millimeters (when the hot end moves towards the bed) klippy.log

it goes into fault mode (flashing red). BLTouch is connected exactly the same as in Marlin install- pin 18 on the Ramps1.4 board, 5v logic mode on the BLTouch.

[ld3300]

I'm not very familiar with delta printers. Can you explain the G91, G28 Z0, G90 process for me. What happens if you just issue G28 without the relative move code? I don't believe adding the 0 after the Z does anything, but I may be wrong.

[gshorten]

Thanks for helping! I am really stuck with this, I have been through all the previous BLtouch posts. Hmmm... I did not enter the G90, G91 codes, although I'm using the Octoprint "home" button (usually) to home the printer - in addition to the G28 home it must be issuing the other commands as well. After homing I issue the klipper code "DELTA_CALIBRATE" (as per the klipper documentation for calibrating a Delta). I have also the same BLtouch problem though if I issue a G28 then DELTA_CALIBRATE , ie not using the octoprint home button instead of g28. BTW running Marlin also auto calibrates (G33 P3), I'm following the same procedure with Klipper - home first then run the calibration routine. Makes no difference if I home with the octoprint button or issue G28 - in Marlin the probe works perfectly, in Klipper it deploys but the probe trigger does not seem to be read.

[KevinOConnor]

Have you completed DELTA_CALIBRATION using the manual method? If not, do that first. Also, make sure that you've completed the steps described in the Config_checks.md document and triple check that the stepper step_distance is correct.

-Kevin

[gshorten]

I've done all the checks in the Config_check.md document, and the stepper step_distance is correct. I did a manual paper test, the nozzle is just dragging at z=0. The printer appears to be working fine, I think the problem is just with the BLtouch. When I run the Delta_calibrate the nozzle descends to the bed, the probe deploys (red light goes out) and as the probe is pushed up when the nozzle descends the bltouch goes into fault. If I raise the head off the bed, manually deploy the probe, and then push the probe up I can feel it slightly buzzing, the red light goes on - this is exactly the same behaviour as when I'm using marlin - except that when using marlin, manually making the pin go down turns on a blue light - I don't see that with klipper, and when the auto calibrate routine runs the probe deploys, the nozzle/bltouch descends to the bed, the probe pushes up, the red light in the probe comes on, and the nozzle/bltouch immediately lifts up 10mm, the probe redeploys, and the nozzle/bltouch moves to the next calibration point. Do I have something wrong in my printer.cfg?

On Sun, Mar 29, 2020 at 10:16 AM KevinOConnor notifications@github.com wrote:

Have you completed DELTA_CALIBRATION using the manual method? If not, do that first. Also, make sure that you've completed the steps described in the Config_checks.md document and triple check that the stepper step_distance is correct.

-Kevin

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-605660869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN45DQ4TH5NYAMAFW6YTRJ5X4HANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

@gshorten

Just some comments, no solutions, but maybe they can help find the problem:

a blue light - I don't see that with klipper

That's normal. Marlin keeps the BLTouch PWM running at the value of the last command ever issued, klipper turns the PWM off after each command. An extinguished blue light or the difference in this behaviour betweeen klipper and Marlin is not an indication of a possible problem.

as the probe is pushed up when the nozzle descends the bltouch goes into fault

I need to assume that the downward movement stops at that moment, though? Otherwise the nozzle would crash into the bed, which you would have stated. So then I assume that klipper has seen the trigger signal (so the pin assignement is correct).

The BLTouch, when probing in normal mode (and NOT in SW, aka "touch"-mode) is programmed internally as follows:

The last command, in this case DEPLOY, sets the probe to "want the pin to be deployed". If it gets pushed in, it will notice and it will issue a trigger signal, but it still "wants the pin to be deployed". Thus the buzzing feeling as it tries a couple of times to push the pin out again. This goes on for about 600ms and then the probes software will give up and go into blinking error state.

This means that firmware that moves stoward the bed must stop immediately on a trigger signal and then EITHER stow the probe prior to 650ms, bringing the probe into "wanting the pin to be up" state OR moving the nozzle/probe up as fast as possible prior to 650ms to get out of the "probe cannot keep the pin deployed" error situation.

---

Test something, maybe:

As the probe moves down, trigger it with your finger somewhere about half way with just short flick, thereby simulating a short quick touch of the bed. Just flick it up and let it falls down again. You then see movement stopping and should see it raise the nozzle and stow the probe with no error blink and then continue (with totally ruined DELTA_CALIBRATION, of course, so it's time to reset everything now).

You might play with increasing the lift_speed parameter in the bltouch section to something faster, like 5 maybe or even more.

And then maybe we can get closer to the problem

[gshorten]

Thanks for the suggestions! I am temporarily back to Marlin to get some parts printed, I will retry Klipper this week...start from the beginning. I'm going to double check that the head is in fact stopping when the probe is pushed up.. I had originally had the BLtouch probe at 3.3v, which worked with the arduino using marlin. When I first set up klipper the nozzle would hit the bed, ie the probe did not stop the z movement, and it did not go into fault either. But after I set the probe to 5v, it appears that it did stop the z movement, but also went into fault. I will check this when I re-install Klipper, make sure that in fact the probe is stopping the z down movement. I will also do a manual delta calibrate as per Kevin's suggestion.

[gshorten]

ok, started from scratch. pushing the probe in while doiing DELTA_CALIBRATE does nothing, nozzle still keeps descending to bed. QUERY_PROBE returns OPEN if probe is up or down. DELTA_CALIBRATE - if I let probe go down to the bed probe deploys, nozzle stops ~ 2mm from bed, bltouch goes into fault. Probe z offset is 3mm

[gshorten]

Tried a probe_calibrate: probe deploys, head moves down, when probe is pushed up it looks like it triggers - the head stops moving down but probe goes into fault , head does not move back up.
Send: PROBE_CALIBRATE Recv: !! Failed to home probe: Timeout during homing

[FanDjango]

Are you on Discord, mabye?

[FanDjango]

Thing is, maybe the timeout occurs because klipper doesn't want to go that far down. Put a small thin object at that place where it should touch, want to see what happens.

[gshorten]

update, I increased z height, now when doing PROBE probe goes into fault, head crashes into bed. So.. same as before, but head was not going all the way to the bed, was just stopping on it's own.. I used same z-height as in Marlin but klipper wants 10 - 15 mm more. Discord? don't know what that is.

[FanDjango]

I need to infer quite lot from your description:

klipper was stopping because it felt it had gone too far (read the messages!)

then:

klipper crashes into bed (no trigger seen, gah!). trigger seen is the first thing to check if it works, otherwise all subsequent tests are not worth their time.

You haven't done the "flick with your finger" test while the head is moving down from a great height, about halfways down. That would be the best proof that klipper actually sees the trigger. And non destructive, at that.

Then:

Instead of crashing into beds, you could put something soft on there for testing purposes, I often use a small towel folded 2 or 4 ways. Or use an empty matchbox. And be ready on the reset button to emergency stop. Adjust heights a little to compensate.

[FanDjango]

QUERY_PROBE returns OPEN if probe is up or down

BLTouch report OPEN = not triggered in up and down position until triggered. You would need to do some tricky work to test that manually.

But you should set pin_up_touch_mode_reports_triggered = True, then klipper will test the probe on the first deploy and then once in while. It knows how to coax the BLTouch into sending a trigger signal, and then you can see if it is seen by your MCU.

Why did you turn this off? I set this to true on my BLTOUCH V3.1

This actually corroborates my feeling that your trigger signal is not seen by the software, somehow.

[gshorten]

Yes, I did the flick with my finger test, sorry I did not clarify that. did not stop the head. I don't think klipper is seeing the trigger.

On Wed, Apr 1, 2020 at 7:08 AM FanDjango notifications@github.com wrote:

I need to infer quite lot from your description:

klipper was stopping because it felt it had gone too far (read the messages!)

then:

klipper crashes into bed (no trigger seen, gah!). trigger seen is the first thing to check if it works, otherwise all subsequent tests are not worth their time.

You haven't done the "flick with your finger" test while the head is moving down from a great height, about halfways down. That would be the best proof that klipper actually sees the trigger.

Then:

Instead of crashing into beds, you could put something soft on there for testing purposes, I often use a small towel folded 2 or 4 ways. Or use an empty matchbox. And be ready on the reset button to emergency stop. Adjust heights a little to compensate.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-607238195, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN45RID7SFWTWQ3RKBZ3RKM4DDANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

I don't think klipper is seeing the trigger.

I don't think klipper is seeing the trigger either

[FanDjango]

Marlin sees the trigger, right?

Check the sensor pin: Is it called sensor_pin = ar18? What board is it? Marlin config.h?

But after I set the probe to 5v, it appears that it did stop the z movement, but also went into fault

That sentence is probably also not reliable, I suppose?

[gshorten]

Yes, Marlin works perfectly. config.h. Marlin sees the trigger, every time. I've changed nothing physically from the marlin setup - same pins, connectors, same physical setup for the BLtouch. Yes, sensor_pin = ar18. Everything else works in Klipper - temperatures, heaters, extruder, stepper motors. re, "unreliable" : what I am saying is that when I saw the head stop (when the probe went into fault) it was probably because the z-height was too small, so the head just stopped before hitting the bed. When I increased the z height the probe went into fault, and the head kept continuing down into the bed, ie the probe did not stop the head. same with the finger test, does not stop the head.

I've tried to follow the Klipper documentation step by step, I've gone through the example files, I must be missing something in the printer.cfg file or it's a bug specific to my system. I think I will give up for now, check back later.

On Wed, Apr 1, 2020 at 7:25 AM FanDjango notifications@github.com wrote:

Marlin sees the trigger, right?

Check the sensor pin: Is it called sensor_pin = ar18? What board is it? Marlin config.h?

But after I set the probe to 5v, it appears that it did stop the z movement, but also went into fault

That sentence is probably also not reliable, I suppose?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-607247109, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN45JWBRFKKQDKGTDAA3RKM6CZANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[gshorten]

I tried both ways. I currently have it to False because that's what the comments in the sample config file suggest:

# Set if the BLTouch consistently reports a "triggered" state after# the commands "pin_up" followed by "touch_mode". This should be# True for a genuine BLTouch v2 and earlier; the BLTouch v3 and some# BLTouch clones require False. The default is True.

On Wed, Apr 1, 2020 at 7:15 AM FanDjango notifications@github.com wrote:

QUERY_PROBE returns OPEN if probe is up or down

BLTouch report OPEN = not triggered in up and down position until triggered. You would need to do some tricky work to test that manually.

But you should set pin_up_touch_mode_reports_triggered = True, then klipper will test the probe at the beginning and later on once in while. It knows how to coax the BLTouch into sending a trigger signal, and then you can see if it is seem by your MCU.

Why did you turn this off? I set this to true on my BLTOUCH V3.1

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-607242011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN427GTCUK5ET3CILMALRKM467ANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

Board type? For the sake of who knows what, why must I pull all the information bit by bit. I know you didn't change the connection setup. But how did you arrive at "ar18"? What makes you so sure that is correct? Even if it probably is. I mean: The same pin might have a different designation in Marlin and in klipper, I would have seen the Marlin configuration.h and gone and checked the boards pin file, done some more checking and then maybe ruled out this possibility, to go on and look for the next possible reason.

I tried both ways. I currently have it to False because that's what the comments in the sample config file suggest:

The docs for those parameters are currently under consideration for being changed or enhanced.

I'll say this again: You should set pin_up_touch_mode_reports_triggered = True, then klipper will test the probe on the first deploy and then once in while. It knows how to coax the BLTouch into sending a trigger signal, and then you can see if it is seen by your MCU.

I tried both ways.

One of those trys should at least have failed with a message saying the probe cannot be verified.

Best of luck getting it to work.

[gshorten]

OK, did some debugging, trying to be as complete as possible. I tried these steps with probe signal connected to ramps1.4 pin 18 (zmin) and to pin 63 (Aux 2 connector), same results on both. BTW to re-iterate the BLTouch works perfectly with the Marlin firmware, so probably not a problem with the BLTouch. It's a genuine BLTouch 3.1

I did this on a clean install of Klipper, latest version

1: pin_up_reports_not_triggered: False QUERY_PROBE: returns OPEN with pin down and up PROBE : The pin goes down, red light off, head starts moving down. pushing pin up turns on red light but head does not stop moving.

2: pin_up_reports_not_triggered: True Same behaviour as above - QUERY_PROBE returns OPEN pin up or down PROBE : pin goes down but does not stop head when manually pushed.

3: pin_up_reports_not_triggered:False Same behaviour as above

4: pin_up_touch_mode_reports_triggered: True QUERY_PROBE returns OPEN with pin up or down PROBE fails with this error: Recv: // BLTouch failed to verify sensor state; retrying.

With the cases 1-3 above (ie, when the PROBE started) I accidentally discovered that If I disconnect the probe signal wire from the BLTouch and touch the wires connecting to the board the head stops, and retracts the probe. The z height is echoed to the terminal. Send: PROBE Recv: // probe at 0.000,-0.000 is z=345.700000 Recv: // Result is z=345.700000 Recv: ok This happens on both pin 18 and pin 63. It's erratic but with repeated touches eventually the firmware sees the signal. Just shorting the wires does not work.

[KevinOConnor]

I'd recommend performing the following steps:

1. Update the printer.cfg file and remove all references to pin_up_touch_mode_reports_triggered and pin_up_reports_not_triggered. (That is, use the default settings for these values.)
2. Grab the latest code - see the FAQ for update instructions - https://www.klipper3d.org/FAQ.html#how-do-i-upgrade-to-the-latest-software
3. Run the steps described at: https://www.klipper3d.org/BLTouch.html#initial-tests . If any test does not complete successfully, do not go on to the next test.
4. Attach the resulting klipper log file to this issue. And describe the results that you found while running the above steps.

-Kevin

[FanDjango]

I would still like to see the Marlin configuration.h and the configuration_adv.h. Is it secret in any way?

[gshorten]

On Fri, Apr 3, 2020 at 11:34 AM FanDjango notifications@github.com wrote:

I would still like to see the Marlin configuration.h and the configuration_adv.h. Is it secret in any way?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608568429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN4Z3Q7B2D6KE2HL5BG3RKYMZBANCNFSM4LVWNMCA .

Sorry, I missed that request. Just standing in line to get in the grocery store, I will send it shortly -- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[gshorten]

Here are the configuration.h and configuration_adv.h

Configuration.h.txt Configuration_adv.h.txt

[gshorten]

1) I updated the software as instructed ( i already did this, with git pull) 2) commented out the two printer.cfg lines, for good measure did a hard reboot. 3) did the BLTouch tests, failed at this point: " The next step is to confirm that the sensor pin is working correctly. Run BLTOUCH_DEBUG COMMAND=pin_down, verify that the pin moves down, run BLTOUCH_DEBUG COMMAND=touch_mode, run QUERY_PROBE, and verify that command reports “probe: open”. Then while gently pushing the pin up slightly with the nail of your finger run QUERY_PROBE again. Verify the command reports “probe: TRIGGERED”. At this stage QUERY_PROBE returned OPEN. Klippy.log attached. klippy.log

[FanDjango]

@gshorten Ok, thx. So standard RAMPS setup. pin ar18 ok. All BLTouch parms ok, no SW mode, everything vanilla.

With the cases 1-3 above (ie, when the PROBE started) I accidentally discovered that If I disconnect the probe signal wire from the BLTouch and touch the wires connecting to the board the head stops, and retracts the probe. The z height is echoed to the terminal. Send: PROBE Recv: // probe at 0.000,-0.000 is z=345.700000 Recv: // Result is z=345.700000 Recv: ok This happens on both pin 18 and pin 63. It's erratic but with repeated touches eventually the firmware sees the signal. Just shorting the wires does not work.

This testing with the wires of the boards pin not connected to the BLTouch is a good idea.

FYI, the BLTouch signal wires, one GND (black) and one SIGNAL (white): The SIGNAL is normal LOW (~0V), like a real switch that is normally closed. So shorting them when they are hanging unconnected will give the normal state = NOT TRIGGERED. When you separate the wires, the white one (depending on the board and the processor) has a mild pull up of a certain strength taking the white wire up to 5V, which is considered to be TRIGGERED signal. If the wires are not shorted and just hanging loose, QUERY_PROBE reports what?

[gshorten]

Also, with the two lines commented out- _

Update the printer.cfg file and remove all references to pin_up_touch_mode_reports_triggered and pin_up_reports_nottriggered. (That is, use the default settings for these values.)

I get this error with PROBE: Recv: // BLTouch failed to verify sensor state; retrying. Recv: !! BLTouch failed to verify sensor state

[gshorten]

Ok, that makes sense now... was wondering about why I was getting a trigger. Yes, standard ramps setup, everything vanilla... although I noticed in configuration_adv I did not have 5v set but it worked anyway :-). I have the white wired as the signal. With probe signal wires disconnected, QUERY_PROBE shows OPEN. I tried a bunch of times.

On Fri, Apr 3, 2020 at 1:32 PM FanDjango notifications@github.com wrote:

@gshorten https://github.com/gshorten Ok, thx. So standard RAMPS setup. pin ar18 ok. All BLTouch parms ok, no SW mode, everything vanilla.

With the cases 1-3 above (ie, when the PROBE started) I accidentally discovered that If I disconnect the probe signal wire from the BLTouch and touch the wires connecting to the board the head stops, and retracts the probe. The z height is echoed to the terminal. Send: PROBE Recv: // probe at 0.000,-0.000 is z=345.700000 Recv: // Result is z=345.700000 Recv: ok This happens on both pin 18 and pin 63. It's erratic but with repeated touches eventually the firmware sees the signal. Just shorting the wires does not work.

This testing with the wires of the boards pin not connected to the BLTouch is a good idea.

FYI, the BLTouch signal wires, one GND (black) and one SIGNAL (white): The SIGNAL is normal LOW (~0V), like a real switch that is normally closed. So shorting them when they are hanging unconnected will give the normal state = NOT TRIGGERED. When you separate the wires, the white one (depending on the board and the processor) has a mild pull up of a certain strength taking the white wire up to 5V, which is considered to be TRIGGERED signal. If the wires are not shorted and just hanging loose, QUERY_PROBE reports what?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608620088, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN44UHAUYLWY3NZGQKI3RKY2UFANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

At this stage QUERY_PROBE returned OPEN. Klippy.log attached.

and

I get this error with PROBE: Recv: // BLTouch failed to verify sensor state; retrying. Recv: !! BLTouch failed to verify sensor state

Ok, noted.

Pin ar18 would seem to be correct. I have gone through your configs.

No we need to brainstorm why klipper is not seeing the HIGH.

Here's a trick: can you plug a real endstop in on the place where you have the BLTouch right now and play with QUERY_PROBE using a real switch?

[FanDjango]

Since you don't need to do homing for this, you can just take the Y_MAX and stick it into the Z_MIN.

[gshorten]

got it. I'll try that and report back.

On Fri, Apr 3, 2020 at 1:44 PM FanDjango notifications@github.com wrote:

Since you don't need to do homing for this, you can just take the Y_MAX and stick it into the Z_MIN.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608625186, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN47KZXZT4EG4RVXINWTRKY4B5ANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

You could also do the opposite: stick the BLTouch (temporarily) into the X_MAX plug, that's your ar2, change the config (temporarily) and do the QUERY_PROBE routine.

Need to narrow down where the problem lies, somehow, and we KNOW that ar2 works, otherwise your homing move to X-MAX would fail. OOOPS - have you ever homed to X-MAX successfully?

[gshorten]

hmmmmm... using the Y_MAX endstop switch in ar18 (I switched the printer.cfg back to pin 18) I get probe: open when the endstop switch is both open and closed.

On Fri, Apr 3, 2020 at 1:44 PM FanDjango notifications@github.com wrote:

Since you don't need to do homing for this, you can just take the Y_MAX and stick it into the Z_MIN.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608625186, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN47KZXZT4EG4RVXINWTRKY4B5ANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[gshorten]

printer homes to all the axis -endstops all work. I just tried putting z max into ar18 , reports open if endstop switch is open or closed ( and I know for sure the endstop works) I can try X_MAX too, we know for sure that works. but AR18 also worked fine with Marlin, so I don't think its a hardware issue like a broken trace.

On Fri, Apr 3, 2020 at 1:56 PM FanDjango notifications@github.com wrote:

You could also do the opposite: stick the BLTouch (temporarily) into the X_MAX plug, that's your ar2, change the config (temporarily) and do the QUERY_PROBE routine.

Need to narrow down where the problem lies, somehow, and we KNOW that ar2 works, otherwise your homing move to X-MAX would fail. OOOPS - have you ever homed to X-MAX successfully?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608629959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN45MG7JCFLYDIDKWBULRKY5OBANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

I think it is time for @KevinOConnor to chime in here again. I think that for a kinematicsa DELTA, the probe pin is somehow not being honored? Can that be? I will look at this some more tomorrow. Its late here now.

But this contradicts that theory:

With the cases 1-3 above (ie, when the PROBE started) I accidentally discovered that If I disconnect the probe signal wire from the BLTouch and touch the wires connecting to the board the head stops, and retracts the probe. The z height is echoed to the terminal.

Thanks for your patience, we'll see where this gets us...

[gshorten]

ok, thanks for all your help.

On Fri, Apr 3, 2020 at 2:25 PM FanDjango notifications@github.com wrote:

I think it is time for @KevinOConnor https://github.com/KevinOConnor to chime in here again. I think that for a kinematicsa DELTA, the probe pin is somehow not being honored? Can that be? I will look at this some more tomorrow. Its late here now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608642205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN4YD5BT736LTIDGL7S3RKZA5NANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[KevinOConnor]

The most recent log that was posted has sensor_pin = ar63. So, I'm a bit confused by the references to ar18. I would double check the config and redo the steps described at https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608617833 .

Note that if you are running a test with an actual endstop switch then you need to use a pullup on the pin description (eg, sensor_pin: ^ar18).

-Kevin

[gshorten]

I changed the pin back, that’s why it is different. But I will do the pull up and report back

On Fri, Apr 3, 2020 at 8:23 PM KevinOConnor notifications@github.com wrote:

The most recent log that was posted has sensor_pin = ar63. So, I'm a bit confused by the references to ar18. I would double check the config and redo the steps described at #2653 (comment) https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608617833 .

Note that if you are running a test with an actual endstop switch then you need to use a pullup on the pin description (eg, sensor_pin: ^ar18).

-Kevin

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608957880, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN46ZNGFG7C36KCQVZPLRK2K2DANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[gshorten]

OK, progress, perhaps. I've connected the Y endstop to ar18, with pullup (^ar18) also, in printer.cfg I have pin_up_reports_not_triggered: True QUERY_PROBE now returns TRIGGERED when the Y endstop switch is closed (ie, carriage pushed up against the limit switch) and OPEN when it is not.

On Fri, Apr 3, 2020 at 8:23 PM KevinOConnor notifications@github.com wrote:

The most recent log that was posted has sensor_pin = ar63. So, I'm a bit confused by the references to ar18. I would double check the config and redo the steps described at #2653 (comment) https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608617833 .

Note that if you are running a test with an actual endstop switch then you need to use a pullup on the pin description (eg, sensor_pin: ^ar18).

-Kevin

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/2653#issuecomment-608957880, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLUN46ZNGFG7C36KCQVZPLRK2K2DANCNFSM4LVWNMCA .

-- Geoff Shorten 403.471.6134 (c)

403.251.6015 (h) 2008 38th Avenue SW Calgary, Alberta T2T 2K4

[FanDjango]

Note that if you are running a test with an actual endstop switch then you need to use a pullup on the pin description (eg, sensor_pin: ^ar18).

Good grief, I am blind. @KevinOConnor thanks.

I mentioned a numerous times, here and in other threads and in a recent PR, BLTouch V3.0 and to a lesser extent, V3.1 have weak capabilities pulling the signal line up. They are to be attached like they were a real switch.

And I talked about pull-up and such stuff above, didn't I?

In your Marlin configuration.h, you have:

#define ENDSTOPPULLUPS //GS for BLTouch

I never thought to advise this for the [blouch] section sensor_pin, as I never needed that on my board. But for many people out there and especially for the V3.0, I think this is mandatory.

So would you please with number one priority check what happens if you specify the BLTouch sensor pin with pull up enabled?

[gshorten]

That fixed everything. immediately worked. I just did a DELTA_CALIBRATE too. Well... I missed it too. I properly set the pull ups on the endstops, but did not think about the BLTouch. ^ on ar18 is all it took. Perhaps should add a note to the BLTOUCH docs to check for this? As you say, probably not required on many systems I also have pin_up_reports_not_triggered: False pin_up_touch_mode_reports_triggered: False also no need to set _output_mode: 5v, works with this commented out. Thanks so much guys. Sorry for taking so much of your time, I should have caught this myself :-( . Looking forward to using Klipper!