BLTouch doesn't always deploy Duet 3 6HC

dc42

Try adding a small delay after deploying the probe. The simplest way is to use the R parameter in the M558 command. 0.1 sec should be sufficient.

Remove the ^ in front of the pin name in the M558 command. It's only needed on Duet 2 when using the Z probe input pin or expansion connector pins. Using it on Duet 3 reduces the noise margin.

ctilley79

@Phaedrux said in BLTouch doesn't always deploy Duet 3 6HC:

G29

It seems to be random. Sometimes it's home all, sometimes it's during my bed level routine. Seems to happen more if the machine has been idle for a while, or after a change in config.g. The odd thing is when i catch it and quickly halt the machine, the next time around it works flawlessly.

@dc42 I'll try adding a delay and see if that helps.

EDIT: Adding a delay did not help. Edited the config and saved., ran homeall after the machine came back up, and probe did not deploy. E stopped the machine and tried again. Probe deployed. at a loss here.

User3D

@ctilley79 My BL-Touch used to go in blink state too ,So I've this line to change its mode to ALARM RELEASE in my config at the end and even at start and end of bed.g . Try this I suppose.
For deployment problem I would suggest you to increase dive height that is H parameter's value in M558 which is 3 right now. Mine is 8.

Phaedrux

Try a slower dive speed as well. The Bltouch likes it slow. Try F120.

Dive height should be a bit more than the trigger height. 2.7 and 3 is pretty tight. Try H5.

How long of a delay did you add with the R parameter? Try R0.5

ctilley79

@User3D It's not going into blink state though. the led is staying solid like it never got the signal to deploy. The bltouch is not erroring out. The next time around though it works.

Phaedrux

That sounds like an intermittent signal issue. May be worth replacing the entire servo signal cable and crimped ends.

ctilley79

@Phaedrux I was afraid you were going to say that

Phaedrux

You could try doing a stress test. Create a macro file with M401 and M402 commands separated by a short G4 S1 pause and have it repeat that many times. See if it can reliable deploy and retract while still. Then try adding some movement commands in between to move the head around while deploying and retracting.

ctilley79

@Phaedrux I like that better. will report back

ctilley79

@Phaedrux Ok. I ran this macro inside a 100 iteration loop a few times while jostling the cable bundle around and the probe worked flawlessly. The dive height you mentioned I see where you're coming from, but let's say my Z axis is at Z130 and I home all. I raise the gantry by a little bit, home x, y, then probe the bed, the probe doesn't deploy even at that height. It's not like it doesn't have enough time to deploy.

Phaedrux

Do you have another BLtouch to test with?

ctilley79

@Phaedrux Not a spare one. Hell, if I have to take this apart I'll use one of the Super Pindas I recently snagged. It's nice being able to probe the actual surface, but I love the fact inductive probes have no moving parts.

ctilley79

@dc42 Ok. I might have some way of repeating this. I left the machine idle for a few hours and ran the below macro. It executed the entire loop and the probe did NOT deploy or retract. Not even once. Using DWC I hit the emergency stop. As soon as the machine came back up I played the macro and the file executed all iterations successfully. It seems this could be related to the machine being idle and no longer being able to send the signal over the io port. I don't think this is a cable or connector issue due to the fact that the machine did not move an inch before or after hitting the estop.

while iterations < 20
	echo iterations
	G4 S1.0
	M401
	G4 S0.5
    M402
    continue

dc42

I suspect that If the firmware thought the probe was already deployed at the start. RRF remembers whether M401 has been used to deploy the probe, and only sends the deploy command if the probe is not recorded as having been deployed. If you send several M401 commands without an intervening M402 command, RRF counts how many M401 commands you sent, and only retracts the probe when you have sent the corresponding number of M402 commands. This is to allow M401 and M402 commands to be used in nested macro files

One consequence of this is that if the probe enters an error state, as well as resetting the error you should send M402 a couple of times to ensure that RRF knows that the probe is retracted.

However, none of this is relevant to G29 probing failing if you have set the probe type to 9 in M558, because for probe type 9 the deploy and retract files are sent every time a point is probed.

ctilley79

@dc42 Ok. I think I may have ruled out the bltouch as being faulty. I just finished a print and let the machine idle for about an hour and the machine would not respond to m402 or m401 commands. Even sending multiple m402 before m401 commands did not help. I also tried M280 P0 S160 to reset the bltouch. The machine was in a homed state and I can manually jog the axis, however If I were to have hit home all, I know the probe would not have deployed.

So what I did was unplugged the bltouch power wires at the extruder. When I restored power, the bltouch went through its startup sequence deploying and retracting twice. I then tried to deploy the probe with M401 and nothing happened. So the bltouch was in a fresh state but the Duet 3 was not. So I e-stopped the machine to restore the duet 3 to a fresh state and the probe worked flawlessly. Should I try a different I/O port?

Phaedrux

Can try io4 or io5.

SneakyTiki

I have a very similar problem, but much easier to replicate, and on different hardware and firmware.

BLTouch will work and deploy flawlessly when I first power on the machine. But as soon as I have used it in a macro (so if I do a G30, or I run a macro to square my gantry, or I run a bed mesh) it will stop responding to commands.
So it will do G30, it will do G29, but only once per power-cycle, and per macro. As a test, I modified my home z to home ( I have a limit switch), probe by my lead screws to tram the gantry, g30 in the middle of the bed, and then G29 to mesh the bed. All of this completes flawlessly. But will only do it once. After it is done, probe doe snot respond to any M280 commands, M401 or M402 commands, nothing. And the blue PWM signal light on it is now out until power-cycle.

I cannot do what I described if I break up the sequence. So if I make a macro to just tram the gantry, I cannot do any of the rest afterwards.

I tried what was recommended earlier, and when on a fresh power-cycle, it will seemingly respond to M280 and M401 and M402 commands indefinitely (I literally pasted thousands of them into a macro and went to lunch, it was still working when I came back)

I wish I could tell you if this is some new behavior, but I have just purchased the BLTouch, and was setting it up for the first time
Oh, it's a BLTouch v3.1

I have it wired through the probe connection.
Configured as follows:

M558 P9 H5 F240 T5000 A4 S0.005 R0.2 B1 ;BLTouch probe (p9), h = dive height, f=z speed, t=travel speed, A=max # of times to probe, s=deviation allowed, r=recovery time, b1=turn off heaters
G31 X-43 Y-5 Z2.102 P25 ;Define the X,Y,Z-offsets of the probe,P=trigger value (25 for BLTouch)

Duet Meastro 1.0, Firmware 2.05.1 (2020-02-09b1)

dc42

@ctilley79 and @SneakyTiki, thanks for your reports. I have added this to my list for investigation.

Is it the case for both of you that once you have run G29, you can no longer deploy the probe by running M401 ? Or is there something else you need to do after running G29 before M401 stops working?

SneakyTiki

@dc42 I sure am glad you asked the question, and I went to confirm before replying.
Clearly I had jumped to some conclusions when first attempting to narrow down the problem and provided an inaccurate report. Here's an update:

Neither G29 nor G30 seem to 'bug' the sensor. Putting them into a macro which simply runs G29, a G0 move, then a G30, also does not 'bug' the sensor.

So I dug deeper and found the cause (at least of my issue, do not want to speak to the problem @ctilley79 has)

My issue was caused by a macro I had which called bed settings after performing things like homing functions, etc.
I went through the commands one by one and found the culprit. It is the M558 command.
For whatever reason, calling M558 P9 (I checked each of the other parameters individually, it's only the P parameter) at any point after the initial power-on reading of config settings, leads to the probe ceasing to respond until power cycle.

Thanks dc42, your pertinent question resolved my problem : D
Time to go fix the macros.

fcwilt

@SneakyTiki said in BLTouch doesn't always deploy Duet 3 6HC:

For whatever reason, calling M558 P9...

Did you call M558 with the complete set of parameters for the BLTouch?

Frederick