BLTouch doesn't always deploy Duet 3 6HC

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.

ctilley79

@Nuramori Is your issue that the probe deploys and doesn't trigger, or are you having an issue with the probe not deploying at all?

Nuramori

@ctilley79 It was that it would deploy but not trigger.

ctilley79

@Nuramori ok. That’s different than my issue. If I can get mine to deploy, it works flawlessly. Mine is not reacting to m401 or m402 commands after a given period of time.

User3D

@ctilley79 I wanna know if you have deployprobe.g and retractprobe.g in /sys only !!!!! (If you do , can you post them here)

ctilley79

@User3D Yes. They are automatically generated if you select P9 as the probe type if i'm not mistaken. Here's a copy of mine

M280 P0 S10 ; deploy BLTouch

M280 P0 S90 ; retract BLTouch

User3D

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

@User3D Yes. They are automatically generated if you select P9 as the probe type if i'm not mistaken. Here's a copy of mine

Yes they are, I just wanted to see if you've changed something that is causing all .

ctilley79

Any update on this? just broke a bltouch probe because of this issue.

SJI

I was having issues on IO_6, no deploy. checked wiring etc, all ok from that end. Changed to IO_7, now it works.