BLTouch only works once on a Duet 3 MB6HC

chrishamm

@hekav Does the BLTouch start flashing when it stops reacting to commands? I've heard of another case where the SBC connection was too slow so the BLTouch entered error mode at some point. You can reduce the communication delay in DSF v3.3 on the Pi by changing SpiPollDelay in /opt/dsf/conf/config.g from 25 to 10 or less. Note that this will increase CPU usage slightly but it may help. Also note that the next version v3.4 will not be affected by this problem.

I presume you have the correct deployprobe.g and retractprobe.g macros in place as well.

hekav

No it does not flash. The red LED is on all the time

deplyprobe.g

; deployprobe.g
; called to deploy a physical Z probe
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Sat Jun 19 2021 20:40:03 GMT+0200 (CEST)
M280 P0 S10 ; deploy BLTouch

retractprobe.g

; retractprobe.g
; called to retract a physical Z probe
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Sat Jun 19 2021 20:40:03 GMT+0200 (CEST)
M280 P0 S90 ; retract BLTouch

I also did some testing with M401 and M402, because I read that the firmware does some sort of stacking with the deploy and retract command. But this did not help.

helmut

Phaedrux

Couple things I notice which maybe won't have any impact.

The X Y position of your G30 is different in homeall and homez. They should be the same point in the center of the bed for consistency.

In your homing files where you call to raise the pin just in case, instead of using M280 P0 S90, use M402 to retract the pin. That way the firmware is updated on the state of the pin.

In your bed.g you should add a single G30 at the center of the bed before and after the tilt correction to ensure the Z0 is accurate.

In your slicer start gcode I don't actually see where you are homing the axis. You have ;G28 XY commented out. Are you manually homing first?

kb58

@phaedrux Regarding: "...In your bed.g you should add a single G30 at the center of the bed before and after the tilt correction to ensure the Z0 is accurate...."

I understand the purpose of the second G30, but what is the system doing with the results of the first G30 and why is it necessary? I ask because my bed.g has only the second G30 and "appears" to be operating correctly, but maybe I'm mistaken.

Phaedrux

More so as a safety to establish where the bed is before trying to correct for tilt in case it's very out of whack.

rkaronde

@hekav What gcode is run at the end of the print? Anything from slicer or stop.g file?

hekav

@Phaedrux
I can homez at the same position, but accurate homing this ist not my problem.

In my homing files I used both M401/M402 M280 P0 S10/90 to retract or deploy the BLTouch. But there were no difference.

When I turn on my printer I call a homeall and the printer is homed as long as i turn off my printer.
When I start a job I only run a G32 to make sure the bed is leveled. Thats why I do not call a G28 XY.
Why should i do that after each job it's wasted time?

helmut

hekav

@rkaronde

M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
G91
G1 Z10
G90
G1 X5 Y380 F6000
;M84
; Shutdown
;M81 S1

Sometimes I uncommet M81 S1 to turn off the printer when I am not present.

Helmut

dc42

@hekav said in BLTouch only works once on a Duet 3 MB6HC:

In my homing files I used both M401/M402 M280 P0 S10/90 to retract or deploy the BLTouch. But there were no difference.

You should not use any of these when using BLTouch.

In your homez.g:

; BLTouch
M280 P0 S160 ; Precautionary alarm release
M280 P0 S90 ; Ensure the pin is raised

I suggest that you either remove those commands, or add a G4 delay command between those two M280 commands. The first one will get overridden almost immediately by the second, and might confuse the BLTouch. You could also add a delay after the second M280 command.

hekav

@dc42

When I started I did not use any of these commands.

Here my original settings:

bed.g

; bed.g
; called to perform automatic bed compensation via G32
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Sat Jun 19 2021 20:40:03 GMT+0200 (CEST)
M561 ; clear any bed transform
G29 S2; Clear bed height map
; Probe 3-point
G30 P0 X10 Y10 Z-9999 ;  Front Left
G30 P1 X190 Y355 Z-9999 ;  Center Rear
G30 P2 X370 Y10 Z-9999 S3 ;  Front Right

homez.g

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Tue Jun 22 2021 09:53:15 GMT+0200 (CEST)
G91                ; relative positioning
G1 H2 Z5 F6000     ; lift Z relative to current position
G90                ; absolute positioning
G1 X15 Y49.7 F6000 ; go to first probe point
G30                ; home Z by probing the bed
; Uncomment the following lines to lift Z after probing
G91               ; relative positioning
G1 Z5 F6000        ; lift Z relative to current position
G90               ; absolute positioning

The results where always the same. Not only the G32 does fail after I run a Job, also the homez command.

I cannot believe that I'm the only having problems like that with the same hardware and software.
I checked the hardware connections several time and used different IO ports, but with no success.

helmut

hekav

I think I found the problem. Since I have a Hemera Extruder I wired all the wires from the print head in one channel to the control board. The length is about 1.8 m. I figured the main difference when printing is the extruder motor. So I made a different cable for the BLTouch and routed it away from the extruder wires. And it works now.

Is it possible that the long path of wires of the BLTouch an extruder in parallel influences the IO behavior of the Duet3 board? Do I have to rewire my printer, or is there an other solution (shielding the BLTouch and/or extruder wires)?

helmut

dc42

@hekav said in BLTouch only works once on a Duet 3 MB6HC:

Is it possible that the long path of wires of the BLTouch an extruder in parallel influences the IO behavior of the Duet3 board?

I'm glad you found the problem. Yes, that is entirely possible. Stepper motor cables induce voltages capacitively to any nearby cables, especially high-impedance signals such as BLTouch in its default open-drain mode. So if you need to route stepper motor wires next to any other cables other than heater or fan power wires, it's best to use shielded cable for the stepper motor cable - ideally, 2 twisted pairs inside a shield. Alternatively, use shielded cable for the signal wires.

Workarounds that may have worked with your original wiring include:

Send BLTouch the command to output a 5V signal instead of operating in open drain mode
Add a pullup resistor of e.g. 3K3 between the BLTouch output and +3.3V
Add a capacitor of e.g. 10nF between the BLTouch output and ground (although that would delay the signal a little)