Optionally handle clone deploy needed when 'stow_on_each_sample: False'

[FanDjango]

See #2655

[FanDjango]

Honestly, I think I would rather tell people that stow_on_each_sample: False cannot be used with a clone probe than implement this addional parameter.

If we ever implement probing in touch mode, that would also be the way to go for clone probes that happen to support touch mode.

[fiferboy]

This worked in my first testing after adding probe_clone_needs_deploy: True to my config.

At some point in my testing, though, my probe stopped deploying which fails every attempt to home or probe now. I tried switching back to the regular branch but the problem persists there and through a power cycle of the printer.

When starting the printer up now instead of getting the "down, up, down, up" test it would normally do I get a "Failed to verify BLTouch probe is raised; retrying." error in the log.

I think this happened the first time I issued a PROBE_ACCURACY command with the new branch, but I'm not sure what would have caused it or why reverting the changes wouldn't correct it. Maybe my probe just gave up at an inconvenient time?

[fiferboy]

In case it would be helpful, here is the log from testing after my probe entered an unresponsive state. I'm guessing there isn't much to go by there.

It looks like this has been closed now. I suppose there isn't much hope of my probe coming back to life. In the absence of any actual conclusion I might have to write my probe off as unfortunate timing of a dead probe.

bltouch2-klippy.log

[KevinOConnor]

I'm not sure why this got closed - something odd with github handling of branches.

-Kevin

[FanDjango]

Hard to imagine. What happens if you disconnect all the wires of the probe and just give it GND and +5V? No self-test?

[fiferboy]

Well, manually deploying the pin and issuing a reset seems to have brought my probe back to life. I have no idea what state it was in, but it is actively working again. I'll re-test this branch and see if it enters that state again, but I would tend to think it was just a strange circumstance unless it occurs again.

[FanDjango]

Very interesting. So it needs a deploy before a reset when it is in a very strange state.

What say you crowd fund a better clone or an original. I will put 1$ in :-))

[FanDjango]

Closing this is fine - I just wanted to put in some code changes for @fiferboy to test.

[fiferboy]

Checking this branch a second time gave me the same behaviour (still recoverable). My pin was deformed from a print failure last night which I thought there was a chance of being the source of the problem. I replaced the pin with a new one and it acts even worse! The self test now ends with the probe in the deployed position (no alarm). I am going to straighten the original pin and retest everything.

What say you crowd fund a better clone or an original. I will put 1$ in :-))

Lol! This is actually my second (and more functional) clone 😆

[fiferboy]

Original pin straightened out and functionality looks good.

Doing a PROBE_ACCURACY without the probe_clone_needs_deploy: True results in the pin bouncing off the build plate every second probe due to the "limp drop" effect.

Unfortunately it is doing the exact same thing with the probe_clone_needs_deploy: True - after the first probe the pin drops and interferes with the next probe. The odd numbered probes are accurate and the even numbered ones are not. The output looks like this:

Send: PROBE_ACCURACY
Recv: // PROBE_ACCURACY at X:155.000 Y:107.000 Z:8.000 (samples=10 retract=2.500 speed=5.0 lift_speed=10.0)
Recv: // probe at 155.000,107.000 is z=2.619992
Recv: // probe at 155.000,107.000 is z=4.365960
Recv: // probe at 155.000,107.000 is z=2.641650
Recv: // probe at 155.000,107.000 is z=4.372624
Recv: // probe at 155.000,107.000 is z=2.613328
Recv: // probe at 155.000,107.000 is z=4.345135
Recv: // probe at 155.000,107.000 is z=2.626656
Recv: // probe at 155.000,107.000 is z=4.360962
Recv: // probe at 155.000,107.000 is z=2.623324
Recv: // probe at 155.000,107.000 is z=4.370958
Recv: // probe accuracy results: maximum 4.372624, minimum 2.613328, range 1.759296, average 3.494059, median 3.493393, standard deviation 0.869123
Recv: ok

This still might be to do with my whacked out pin, but using the pin_up and pin_down commands work fine without the limp drop. Most mysterious of all, when I used the new pin and issued a pin_down command it would pull the pin up. When I issued a pin_up command to would deploy the pin. I have no idea, other than maybe the new pin has the polarity reversed on the probe magnet? Would that cause this effect?

[FanDjango]

pin bouncing off the build plate every second probe due to the "limp drop" effect

This is when using the stow_on_each_sample: False. Hmmmm. This going up and dropping down happens even when you do not say probe_clone_needs_deploy: True right? That means that your strange probe will do a pin-up/drop-down action when triggered, all by itself? Test that with the nozzle up high, use BLTOUCH_DEBUG to deploy and trigger with your finger veeeerryy gently, see what the pin does and tell me, I'm curious

[FanDjango]

Oh, and the drop wouldn't be so bad if it didn't bounce, right? Does it really bounce up and down again, once or a couple of times?

[fiferboy]

Yes, the behaviour is the same regardless of probe_clone_needs_deploy. My recollection (print is currently running, I'll check in more detail later) of the probe process is:

• pin deploys for probing and Z axis moves towards build plate
• pin triggers and attempts to retract while Z axis moves away from build plate.
• retract seemingly fails and drops to pin again (not a deploy move, just the pin dropping on its own)
• Z axis starts moving toward the build plate while the probe attempts the retract again (usually successful this time around)
• pin deploys but the Z axis has moved past the trigger point causing an immediate retract

The only thing wrong with the drop is that it seems to mess up the next probe if it comes too quickly - maybe setting a higher lift between probes would work fine.

Now, this could very well be caused by something I have done - either my pin is too messed up at this point (seems to be fine other than a bit of a 'wow' in the middle), or no longer properly magnetized, or my probe has taken one hard hit too many. The only reason I don't discount the probe altogether is because of how beautifully it worked on your monolithic rewrite branch from a few months ago - probing was a dream back then (the branch that changed the timing and removed the pin_up_touch_mode_reports_triggered and changed the BLTOUCH_DEBUG command names).

[FanDjango]

I still have it and it is rebased to the current master. I have changed it such that it is a [bltouch_fandjango] section, thus it can live side by side with the normal one - it's like a second "kind" of bltouch. But the motivation to have it has gone down to near zero with the current state of the official code, Kevin has worked wonders. I am surprised that your little probe of horrors worked well with that and not with this new official version. We could still search for that, for the reason, or you just try out [bltouch_fandjango], but is it worth it?
Maybe I will just send you a 3.1 by mail, and then you send me your probe in return and I will play with it. Dunno... and I don't want to alienate Kevin, either, on this. It's his code and he's been really good with this stupid bltouch stuff, which is so very much more problematic than a simple switch.
Think about it for a while.

[fiferboy]

I agree that it doesn't make sense to complicate the code for what seems to be a single probe gone wild. I would have thought the TriangleLab probe would be fairly popular so if more people aren't having the same problem it could definitely be something about my setup.

I did try the [bltouch_fandjango] probe a while back but I never got it to work properly (but this was before I could flash my MCU conveniently so I may have neglected to flash for that branch if it would make a difference >_> ) I think I may actually have checked out that file in the master branch and there was a difference in how the homing worked.

I'll give that branch another go and see if it has that same glorious behaviour or whether my probe has deteriorated to the point where this is the best I will be able to do.

Thanks for your help with all this - I appreciate the time you and @KevinOConnor have put into this (and Kevin with everything else he does on top of that).

[FanDjango]

Give me some more days to fix up the branch according to some new stuff and then we'll see. I haven't pushed it for I while. I'll tell you when