3.3RC1 Duet2 SBC Problems with Bltouch

Phaedrux

@nmsmith89 In your case I think this is a known limitation in RRF3.

Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.4.
If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.4.

https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations

@lahn92 you're using a Duet2 modded to use the SBC connector, so I'm not sure how that limitation would affect you if at all. Will check.

lahn92

@phaedrux
so tried removing my PT100 sensor and paneldue from my config to see if that was making somekind of problem.
it did not help.

busy grasping at straws here

dc42

@lahn92 and @nmsmith89, the only reason I can think of why the Z probe triggering might be detected late is if either the BLTouch has a lot of leakage when it is triggered, or there is a lot of interference picked up by the BLTouch output wire (e.g. from an adjacent stepper motor cable); and the internal pullup resistor on the zprobe.in pin isn't sufficient to counter the interference or leakage.

Here are two possible solutions:

If your Duet 2 is version 1.04 then you can send a command to the BLTouch to pull the output to 5V when triggered, instead of relying on the pullup resistor.
You could connect an external pullup resistor between Z probe in and +3.3V pins. I suggest a value between 2.2K and 10K.

The limitation referred by @Phaedrux only applies to CAN-connected expansion boards.

lahn92

@dc42

any instructions on doing number 1. as i at the moment i dont have a resistor handy?

edit:
is it this

dc42

@lahn92 yes it's that. The Duet 2 1.04 and later can tolerate 5V input from the BLTouch.

lahn92

@dc42 Tried it, it did not change anything.

but i think the problem lies in deployment and retraction of the probe

because if io do a repeatability test with the following code it does not hang anywhere. as it does not deploy and retract the probe between touch off.

M291 P"Probe will be tested 10 times and return mean and standard deviation. Ok or Cancel?" R"WARNING" S3 ; User must click OK or cancel.
M401
G28 Z
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P0 X100 Y101 Z-9999
G30 P9 X100 Y101 Z-9999 S-1
M402

is there maybe a way to get it to not retract and deploy the probe between each point in a G29, as a quick fix solution?

dc42

@lahn92 said in 3.3RC1 Duet2 SBC Problems with Bltouch:

is there maybe a way to get it to not retract and deploy the probe between each point in a G29, as a quick fix solution?

Yes, if you use P8 instead of P9 in the M558 command then it will do that. But that may fail, because after triggering the probe will extend immediately again; and if the Z axis is not fast enough then it may trigger immediately and go into the error state.

lahn92

@dc42 Will try that tomorrow

lahn92

@dc42

so i have tried two things today.

first i tried running with the probe set as P8 and this seems to work just fin.
video

then i tried to switch out my current BlTouch 3.1 to an older 2.2 running as a P9.
this BlTouch does not have the same issue as the 3.1 but instead does a double bounce on retraction.
video

with both it does not seem to error out the Bltouch, but the 3.1 still seems to experience the hang up when deploying and retracting.

dc42

@lahn92 please update to release 3.3RC2 from the package server.

lahn92

@dc42
tried updating, and after that i also tried reinstalling duetpi-lite.
both have not changed my problem

Phaedrux

And confirmed that RC2 was actually flashed to the duet?

lahn92

@phaedrux

Yup

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 SBC FIRMWARE_VERSION: 3.3RC2 ELECTRONICS: Duet 2 1.02 or later + SBC + DueX5 FIRMWARE_DATE: 2021-05-11 14:55:15

Phaedrux

Thanks, just wanted to make sure.

chrishamm

@lahn92 If you are able to edit config files on the Pi, please try to change SpiPollDelay from 25 to 1 in /opt/dsf/conf/config.json and then restart DCS via sudo systemctl restart duetcontrolserver. This should reduce the response time before the BLTouch pin is deployed/retracted, but it will increase the CPU load on the Pi a bit. Please let me know if that fixes your problem.

lahn92

@chrishamm

made the changes you suggested, and it is getting it to a working state. there still seem to be a noticeable delay that changes from probe to probe. but none of them are long enough to error out the BLtouch.

so its working, but not sure if it behaving as intended. but maybe as good as it gonna get on a pretty unusual config.