BLTouch doesn't always deploy Duet 3 6HC

[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

[dc42]

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

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 for reporting this. Can you confirm that you only ever used P9 in your M558 commands, and not some other P value?

Repeating the M558 command will cause the probe to be set up again, but it shouldn't cause it to stop working, provided that you always use P9 with a BLTouch.

[SneakyTiki]

@fcwilt Yes, it was the full config code for the sensor. My config.g only calls macro files, all of them printer_"something".g related to whatever I am defining (I prefer the organization that way) And in printer_bedmesh.g I had the configuration for the probe, which was:

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)

All of my homing sequences (as well as bed.g) call this file to restore the saved heightmap after completing. I set it up that way because when this printer was in its previous barbaric state with no probe, I had set up different heightmaps by temperature, and wanted a centralized place to change the name of the heightmap I wanted to call and it affect everything at once.

I simply moved the probe definition into my printer_tools.g file and all is working as intended.

But after dc42 asked his question, I did some tooling around. All of the other M558 parameters (and M558 on its own) do not negatively impact the probe. It is when I send M558 P9 that makes the probe unresponsive.

[SneakyTiki]

@dc42 That I can confirm, it was the exact same code that ran at start-up, my macros just happened to call it multiple times throughout normal printer operation after initial power on (It lived in a file called printer_bedmesh.g, which was called by config.g on startup, but also by homez.g, homeall.g, and bed.g)

And when I was narrowing it down after your question, I literally just powered on the printer, sent M401, M402 to confirm operation, then sent M558 P9 and M401 and M402 no longer responded.

[fcwilt]

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

@fcwilt Yes, it was the full config code for the sensor.

Here is my probe configuration macro. It is called in several places.

M950 S0 C"duex.pwm5"                                ; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H2 F120 T12000 R0.2 A1 S0.03  ; set type for BLtouch and set default parameters
G31 P25 X0 Y24.5 Z2.400                             ; set trigger value, offset and trigger height (larger = closer)

BUT this is under firmware 3.2.0 running on a Duet 2 WiFi/Duex 5 combo.

---

I have a spare BLTouch - I will connect it to my Duet 3 MB6HC and set what happens.

Frederick

[SneakyTiki]

@fcwilt I was also surprised to find an issue that sounded similar to mine considering the user had completely different hardware and firmware to me. But hey, glad I looked, helped me fix my issue. Maybe it'll help someone else

[Nuramori]

Your “P500” in your config.g may be too high. I had a similar issue a while back, and I have mine set at P100. I haven’t had an issue since.

[Veti]

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

Your “P500” in your config.g may be too high. I had a similar issue a while back, and I have mine set at P100. I haven’t had an issue since.

the bltouch is digital. the signal is either 0 or 1000.

[ctilley79]

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

In my case, g29 isn’t really involved. I ran g29 several times in succession and that didn’t seem to lock up the probe. I can home the machine, deploy and retract the probe just fine, walk away for an hour, and when I come back the probe is unresponsive. I’ll do some more investigation today. Switching io ports didn’t help for me.

[ComedianTF2]

I've had a similar issue, and managed it to narrow it down to the yellow BLTouch cable not being connected properly. I did a quick check disconnecting the cables one by one, and homing, and these are the results:

• white cable: no self-test, red LED on like normal, Z-probe value 1000, ejects pin but instantly retracts it and errors out
• black cable: no self-test, red led like normal, z-probe value 0 until homing, then goes to 1000 and errors out
• Yellow cable: completes self test, red LED works like it should, the Z-probe value is 0, but does not detect the homing, and will continue to move down even after pin gets disturbed
• red cable: does not do self test, no red LED, Z-probe value 1000
• brown cable: completes self test, red LED works, Z-probe value 0, ejects pin, works like normal

Note that my bltouch does not always do the self-test on bootup, and I'm not sure why so that part of the test might not be accurate

This is with a Duet 2 on RRF2 by the way

[Nuramori]

@Veti there was an issue in a previous firmware version that P500 was a problem, and reducing it to P100 would help, per David’s suggestion. It did. After that version I went back to P500 as a mid value and the problem re-emerged. Going to P100 fixed it, so I’ve kept the value.