3.3RC1 Duet2 SBC Problems with Bltouch

Phaedrux

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

G31 P900 X-14.65 Y19,29 Z3.24 ; Set Z probe trigger value, offset and trigger height

Not sure if it matters but it looks like you're using a comma instead of a period in Y19,29

You can send G31 by itself in the console to see what it has interpreted the value as.

Also, for the BLtouch try G31 P25. And your dive height is a bit high. Try M558 H5. And dive speed a bit fast. Try M558 F120.

lahn92

@phaedrux
my dive hight and speed was normally what you sugested but changed it trying to diagnose the problem.

but i have changed it back now to test

also changed the G31

; Z-Probe
M950 S0 C"duex.pwm1"                                  ; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H5 F120 T9000                   ; Set Z probe type to bltouch and the dive height + speeds
G31 P25 X-14.65 Y19.29 Z3.24                         ; Set Z probe trigger value, offset and trigger height
M557 X20:222 Y15:215 S30                              ; Define mesh grid

it homed z fine, ran G29 2 times and both times it failed within the first 5 probes

Edit: just had it happen on a z-axis home

M122 from right after

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 SBC version 3.3RC1 (2021-05-01 09:58:40) running on Duet 2 1.02 or later + SBC + DueX5 (SBC mode)
Board ID: 08DGM-9T6BU-FG3S8-6J1DJ-3SN6M-1SLBG
Used output buffers: 1 of 24 (23 max)
=== RTOS ===
Static ram: 17420
Dynamic ram: 63144 of which 0 recycled
Never used RAM 30996, free system stack 126 words
Tasks: SBC(ready,13.4%,291) HEAT(delaying,0.1%,331) Move(notifyWait,0.2%,305) DUEX(notifyWait,0.0%,24) MAIN(running,86.3%,479) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 02:04:30 ago, cause: power up
Last software reset at 2021-05-09 07:30, reason: User, none spinning, available RAM 30788, slot 1
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 31.8, current 38.1, max 38.6
Supply voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/24/12, gc cycles 0
Driver 0: position 9600, standstill, SG min/max 0/301
Driver 1: position 8800, standstill, SG min/max not available
Driver 2: position 3296, standstill, SG min/max 65/299
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max 0/293
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max 0/634
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-05-09 09:40:37
Cache data hit count 4294967295
Slowest loop: 784.16ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
DMs created 83, maxWait 7403072ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 6, completed moves 6, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Filament sensors ===
Extruder 0 sensor: no filament
=== DueX ===
Read count 1, 0.01 reads/min
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 4ms ago
RX/TX seq numbers: 61060/61060
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x0d08c
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3-rc1
Daemon:
Finishing macro daemon.g, started by system
> Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 34.10
Codes per second: 0.12
Maximum length of RX/TX data transfers: 3632/700

nmsmith89

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.

lahn92

@nmsmith89
interresting, i was thinking it was something more to do with it being duet 2 and sbc

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.