3.3RC1 Duet2 SBC Problems with Bltouch
-
I have the exact same problem and for the life of me I can't figure it out.
I'm running a Duet 3 Mini 5+ in SBC mode. Also have the BLTouch connected to a Toolboard 1LC.
I've checked the wiring and everything and it all seems fine. Diving faster seems to help a little bit but doesn't solve the problem.
From what I can tell it's the combination of 2 factors that causes the problem to happen:
-
The BLTouch will go into error mode of it sits triggered for too long. Something like more than 750ms or around there. As far as I can tell this behaviour is intended.
-
At least with my setup, when probing and the BLTouch is triggered there seems to be a random amount of time before the printer reacts to the trigger. Sometimes it's almost right away and sometimes it's a little bit of a pause.
When the printer pauses long enough after a probe trigger, the delay causes the probe to go into error mode.
I don't have any idea how to fix it but this is at least my working theory so far. It's possible it may have something to do with SBC mode. Our printers both have that in common. Maybe the presence of the SBC/Pi introduces a slight delay in between commands and/or reactions.
@dc42 should be able to tell us if a delay does exist in SBC mode and if, per my theory, that could pose a problem for the BLTouch in some specific setups.
-
-
@nmsmith89
interresting, i was thinking it was something more to do with it being duet 2 and sbc -
@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.
-
@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
-
@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.
-
-
any instructions on doing number 1. as i at the moment i dont have a resistor handy?
edit:
is it this
-
@lahn92 yes it's that. The Duet 2 1.04 and later can tolerate 5V input from the BLTouch.
-
@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?
-
@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.
-
@dc42 Will try that tomorrow
-
so i have tried two things today.
first i tried running with the probe set as P8 and this seems to work just fin.
videothen 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.
videowith 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.
-
@lahn92 please update to release 3.3RC2 from the package server.
-
@dc42
tried updating, and after that i also tried reinstalling duetpi-lite.
both have not changed my problem -
And confirmed that RC2 was actually flashed to the duet?
-
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
-
Thanks, just wanted to make sure.
-
@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 viasudo 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. -
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.