Bltouch not always triggering during bed probe

emofes

Our bltouch started randomly stopping mid probe. Sometimes its on the first probe, sometimes later but it never finishes the entire bed anymore. Also sometimes its seems to lag between probe moves occasionally. The probe used work but seems to have slowly gotten worse over time to where now its 50/50 whether the pin will retract or not.

I'm guessing it may be a wiring issues or something with the probe itself? Its fairly large printer with a long run for the cable from the hotend to the mainboard, could interference be a problem?

; Z-Probe
M950 S0 C"exp.heater3"                                            ; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H5 F200 R0.2 T15000        ; set Z probe type to bltouch and the dive height + speeds
G31 P25 X-14.9 Y-30.5 Z0.9                                        ; set Z probe trigger value, offset and trigger height
M557 X0:335 Y0:300 P4                                             ; define mesh grid
M376 H10                                                                     ; Set bed compensation taper

I have a video of the problem but not enough reputation to posy it yet.

droftarts

@emofes I've given you some reputation, so you can now post links.

Is the BLTouch in a heated chamber? They are quite susceptible to heat, which causes them to fail. Otherwise, check the wiring for loose connections. It's also possible that the wires have fatigued with the motion of the printer, and need to be replaced.

Ian

emofes

@droftarts its on old Fusion3 F410. The chamber is not actively heated but the printer is enclosed and we sometimes times run the bed up to 100°C. It doesn't have issues resetting the probe or running the stow, deploy, or self test commands. I will check the wiring connections today.

https://youtu.be/hsXuTimmcVM

droftarts

@emofes From your video, I'd say the issue was with the probe. The Z seems to stop when the probe is triggered, and the probe retracts on the first three probe attempts. On the third probe, there does seem to be a delay before probe moves on. On the fourth probe, the Z stops when the probe is triggered, but the pin doesn't retract, and the probe goes into fault mode. I think the pin is probably sticking, or needs adjustment. From this page: https://www.3dprintbeast.com/bltouch-blinking-red/

The BLTouch can blink red in two different patterns, where the blinking is fast in one (50% uptime of the LED) and slow in the other (80% uptime of the LED), with each pattern signaling a separate issue.

I'd say the error pattern is the first pattern. While it says this happens during self-test, it also happens during operation.

BLTouch Blinking Red Quickly

The first BLTouch red LED pattern that signifies an error is when the LED flashes quickly with an uptime of 50%.

A quickly flashing red LED on the BLTouch tells us that the BLTouch is in alarm mode due to failing the self-test process where the probe conducts the necessary checks before becoming ready.

As the BLTouch going into alarm mode can be a result of many different things that go wrong during the self-test process, here is a list of the common culprits that accommodate most cases but isn’t exhaustive:

Obstruction of the pin, causing it to be incapable of moving up and down freely, which can be due to either internal factors (damaged probe) or external factors (dust, dirt, etc.)

The pin hitting the build plate

Issues with the homing of the Z-axis, such as the speed being too slow

Physical damage to the probe, preventing the pin from functioning correctly

Firmware issues

Defective probe

While this list isn’t exhaustive by any means, as we have mentioned, it should give you a good idea of why the probe can go into alarm mode.

You can also adjust the 'core'. There isn't much explanation about what this does, though. See https://www.antclabs.com/_files/ugd/f5a1c8_d40d077cf5c24918bd25b6524f649f11.pdf

If push-pin deploy fails, turn the core by up to 180 degrees with an Allen-key so that the core is further inside the casing.

Perhaps if the opposite is true, ie fails to retract, unscrew the core 180 degrees so it is nearer the top.

Ian

emofes

@droftarts Thanks Ian, I will mess with the pin and see if that does anything. I also have a cr touch and knockoff bltouch at home I can test out or swap the pins from.

emofes

@droftarts
I did some more testing, and it seems like the issue might be a symptom of a bigger problem related to DWC or the printers network connection. The printer is running a Duet 2 Ethernet board connected via Ethernet to a router that is not connected to the internet, just this printer, a Bambu printer in LAN mode, and some Hue lights.

When the printer is connected to the router, it usually fails to finish probing and randomly lags between moves, like in the video I posted earlier. Also, when I connect to the printer’s browser interface, it will randomly disconnect and reconnect. This seems to happen more frequently if I use Safari on an iPad versus Firefox on a Windows machine, but it occurs on both.

If I disconnect the printer from Ethernet, it seems to probe and print fine, no lagging or failed probe points.

A few things I'm wondering:

Are there any commonly known issues that would cause frequent network disconnects?
The controller is in an enclosure, and the Ethernet cable runs over the power supply; could there be an interference issue?
The Ethernet cable connects to a coupler so that another Ethernet cable can be connected outside the enclosure. Maybe the coupler or one of the cables is bad and causing random disconnects?
Could a problem with DWC or the Ethernet connection be causing interrupts?
Could using input shaping, mesh bed leveling, DWC, etc. be too much for the board to handle at once?

droftarts

@emofes What firmware are you running? Send M122 and post the results.

I would think that there's something on the network that is generating a lot of traffic. You could try doing a WireShark trace. Or disconnect other devices, and see it there's one that's causing the issue.

Ian

emofes

@droftarts

m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.4 (2024-11-24 10:43:42) running on Duet Ethernet 1.02 or later
Board ID: 0JD0M-9P6B2-NJ4S4-6JTDL-3S46R-KS0AM
Used output buffers: 6 of 26 (24 max)
=== RTOS ===
Static ram: 23488
Dynamic ram: 68672 of which 208 recycled
Never used RAM 17200, free system stack 108 words
Tasks: NETWORK(1,ready,15.4%,181) HEAT(3,nWait 5,0.1%,307) Move(4,nWait 5,3.5%,268) MAIN(1,running,81.0%,742) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 06:53:31 ago, cause: reset button or watchdog
Last software reset at 2025-04-26 13:54, reason: User, Gcodes spinning, available RAM 16940, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,1,0
MCU temperature: min 34.8, current 36.7, max 38.6
Supply voltage: min 23.0, current 23.4, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/300/300, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 2025-04-29 14:48:45
Cache data hit count 4294967295
Slowest loop: 1851.79ms; fastest: 0.15ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 250.0ms, write time 2.1ms, max retries 0
=== Move ===
DMs created 83, segments created 44, maxWait 56969ms, bed compensation in use: mesh, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin -0.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 29505, on retry 6213, too short 24299, wrong shape 702764, maybepossible 1420
=== DDARing 0 ===
Scheduled moves 824009, completed 824009, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== Filament sensors ===
check 77714844 clear 4016894
Extruder 0: pos 2398.71, errs: frame 92 parity 0 ovrun 631 pol 11 ovdue 0
=== Network ===
Slowest loop: 221.55ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 3 of 8
Interface state active, link 100Mbps full duplex
Socket states: 5 2 2 2 2 2

droftarts

@emofes said in Bltouch not always triggering during bed probe:

A few things I'm wondering:
Are there any commonly known issues that would cause frequent network disconnects?

Not with the Ethernet boards, they're pretty solid. There have been ups and downs with the WiFi versions over the years, but as far as I'm aware that's fixed now.

The controller is in an enclosure, and the Ethernet cable runs over the power supply; could there be an interference issue?

Possibly. If possible, re-route the Ethernet cable away from the PSU. It could be picking up interference, that is somehow interfering with the BLTouch servo control or signal wires.

The Ethernet cable connects to a coupler so that another Ethernet cable can be connected outside the enclosure. Maybe the coupler or one of the cables is bad and causing random disconnects?

Again, possibly, and similar to above, it may be picking up interference. You could try replacing the two-part cable with a single cable, temporarily.

Could a problem with DWC or the Ethernet connection be causing interrupts?

Like I said, something spamming the network might generate traffic that is interrupting the Duet. Your M122 command shows this:

=== Network ===
Slowest loop: 221.55ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 3 of 8
Interface state active, link 100Mbps full duplex
Socket states: 5 2 2 2 2 2

"Responder states" indicates what the protocol is currently doing, see the list here. 0 indicates it's currently 'free'.
"Http sessions" indicates there are 3 HTTP sessions. Are you connecting multiple browser tabs to the Duet? Reducing the number of HTTP sessions will help connectivity, ie close browser windows connected to the Duet that you are not using will free up the session.
"Socket states" indicates what the network sockets are actually doing, from the list here in RRF 3.5.4, where 2 is 'listening' (which means it is currently available) and 5 is 'closing' (if you ran M122 again, it's state would probably change to 2).

So from this M122, nothing is happening, and most sessions and sockets are available. If you can grab an M122 during mesh levelling, it might be more revealing.

If the chip receives too many connection requests at once, the rest may be aborted, and that leads to connectivity issues. If you increase the number of HTTP sockets by disabling FTP/Telnet (if you are not using them, and have them enabled in config.g with M586), it's less likely to happen.

You haven't posted your full config.g, which might help.

Could using input shaping, mesh bed leveling, DWC, etc. be too much for the board to handle at once?

Not as far as I'm aware. The MCU on the Duet 2 WiFi/Ethernet is the same as on the Mini 5+, computationally. It is limited by flash memory and RAM, but @dc42 works hard to keep it functional.

Ian

emofes

@droftarts

"Http sessions" indicates there are 3 HTTP sessions. Are you connecting multiple browser tabs to the Duet? Reducing the number of HTTP sessions will help connectivity, ie close browser windows connected to the Duet that you are not using will free up the session.

I had a browser tab, orca slicer, and another browser tab on an ipad open at the same time.

Here is an M122 response while the mesh leveling is running.

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.4 (2024-11-24 10:43:42) running on Duet Ethernet 1.02 or later
Board ID: 0JD0M-9P6B2-NJ4S4-6JTDL-3S46R-KS0AM
Used output buffers: 8 of 26 (26 max)
=== RTOS ===
Static ram: 23488
Dynamic ram: 68840 of which 208 recycled
Never used RAM 17032, free system stack 108 words
Tasks: NETWORK(1,ready,86.9%,181) HEAT(3,nWait 5,0.0%,307) Move(4,nWait 5,0.0%,260) MAIN(1,running,13.1%,713) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 21:36:23 ago, cause: reset button or watchdog
Last software reset at 2025-04-26 13:54, reason: User, Gcodes spinning, available RAM 16940, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 35.2, current 35.5, max 35.4
Supply voltage: min 23.4, current 23.4, max 23.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/308/304, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 2025-05-01 13:45:20
Cache data hit count 4294967295
Slowest loop: 313.31ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 250.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 44, maxWait 1354ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 1, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 1620434, completed 1620434, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by HTTP
HTTP is idle in state(s) 0 32 0, running macro
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== Filament sensors ===
check 152917475 clear 131475970
Extruder 0: pos 13909.57, errs: frame 58 parity 0 ovrun 410 pol 6 ovdue 0
=== Network ===
Slowest loop: 7.36ms; fastest: 0.04ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
Interface state active, link 100Mbps full duplex
Socket states: 2 2 2 2 2 2

Here is the full config.g

; Configuration file for Duet WiFi (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Mon Aug 14 2023 15:59:26 GMT-0500 (Central Daylight Time)

; General preferences
M575 P1 S1 B57600                                                 ; enable support for PanelDue
G90                                                               ; send absolute coordinates...
M83                                                               ; ...but relative extruder moves
M550 P"Fusion3 F410"                                              ; set printer name
M669 K1                                                           ; select CoreXY mode

; Network
M551 P"reprap"                                                    ; set password
M552 S1 P10.0.0.4                                                 ; enable network and set IP address
M553 P255.255.255.0                                               ; set netmask
M554 P192.168.1.1                                                 ; set gateway
M586 P0 S1                                                        ; enable HTTP
M586 P1 S0                                                        ; disable FTP
M586 P2 S0                                                        ; disable Telnet

; Drives
M569 P0 S1                                                        ; physical drive 0 goes forwards
M569 P1 S1                                                        ; physical drive 1 goes forwards
M569 P2 S0                                                        ; physical drive 2 goes backwards
M569 P3 S0                                                        ; physical drive 3 goes backwards
;M569 P4 S0                                                       ; physical drive 4 goes backwards
M584 X0 Y1 Z2 E3                                                  ; set drive mapping

; original extruder value
;M92 X44.00 Y44.00 Z426.67 E192.10                                ; set steps per mm
M92 X44.00 Y44.00 Z426.67 E690.0                                    ; orbiter v2.5 extruder
M350 X16 Y16 Z16 E16 I1                                           ; configure microstepping with interpolation
;M566 X300.00 Y300.00 Z60.00 E300.00
M566 X600.00 Y600.00 Z60.00 E600.00                                  ; set maximum instantaneous speed changes (mm/min)
;M566 X300.00 Y300.00 Z60.00 E950.00                              ; set maximum instantaneous speed changes (mm/min)
M203 X33000.00 Y33000.00 Z2500.00 E7200                           ; set maximum speeds (mm/min)
M201 X3500.00 Y3500.00 Z1000.00 E5000.00
;M201 X5000.00 Y5000.00 Z1000.00 E3000.00
;M201 X10000.00 Y10000.00 Z300.00 E12000.00                       ; set accelerations (mm/s^2)
;original extruder value
;M906 X1300 Y1300 Z1400 E1400 I10                                 ; set motor currents (mA) and motor idle factor in per cent
M906 X1300 Y1300 Z1400 E1200 I80                                  ; orbiter v2.5
M84 S30                                                           ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z-10 S1                                                 ; set axis minima
M208 X355 Y340 Z350 S0                                            ; set axis maxima

; Endstops
M574 X1 S1 P"xstop"                                               ; configure switch-type (e.g. microswitch) endstop for low end on X via pin xstop
M574 Y1 S1 P"ystop"                                               ; configure switch-type (e.g. microswitch) endstop for low end on Y via pin ystop
M574 Z2 S1 P"zstop"                                               ; configure switch-type (e.g. microswitch) endstop for high end on Z via pin zstop

; Z-Probe
M950 S0 C"exp.heater3"                                            ; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H3 F500 R0.8 T25000                               ; set Z probe type to bltouch and the dive height + speeds
G31 P25 X-14.9 Y-30.5 Z2.0                                           ; set Z probe trigger value, offset and trigger height
M557 X0:335 Y0:300 P4                                             ; define mesh grid
M376 H10                                                          ; Set bed compensation taper

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4036 R4700              ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                                             ; create bed heater output on bedheat and map it to sensor 0
M307 H0 A153.5 C534.2 D6.7 B0                                     ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0                                                           ; map heated bed to heater 0
M143 H0 S140                                                      ; set temperature limit for heater 0 to 140C
M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C0.0000000706 R4700 ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                                              ; create nozzle heater output on e0heat and map it to sensor 1
;original volcano heater values
;M307 H1 A338.3 C210.6 D3.6 B0                                    ; disable bang-bang mode for heater  and set PWM limit
M307 H1 R3.933 K0.537:0.000 D4.26 E1.35 S1.00 B0                  ; CHC Pro heater values
M143 H1 S320                                                      ; set temperature limit for heater 1 to 320C

; Fans
M950 F0 C"fan0" Q500                                              ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1                                                    ; set fan 0 value. Thermostatic control is turned off
;M950 F1 C"fan1" Q500                                 ; create fan 1 on pin fan1 and set its frequency
;M106 P1 S1 H1 T45                                    ; set fan 1 value. Thermostatic control is turned on

; Tools
M563 P0 S"extruder0" D0 H1 F0                                     ; define tool 0
G10 P0 X0 Y0 Z0                                                   ; set tool 0 axis offsets
G10 P0 R0 S0                                                      ; set initial tool 0 active and standby temperatures to 0C

; Custom settings
; Configure filament monitor
;M581 T2 E0 S0 C1
;M591 D0 P3 C"e0stop" S0
M591 D0 P3 C"e0stop" S1 R60:160 L25.06 E5.0

;Input shaping
;M955 P0 I25 C"spi.cs2+spi.cs1" ; all wires connected to temp DB connector, no temperature daughterboard
M593 P"mzv" F40

;Debug logging
M929 P"debuglog.txt" S3

T0                                                                ; select first hot end

emofes

@droftarts I also forgot to mention it is more likely to fail if I initiate a print or bed leveling from the web interface vs from the panel due. I just ran a bed level and handful of times and every time I used the panel due worked fine, every time I used the wed interface it eventually failed before probing all the points.