3.1.1 - BLtouch doesn't function after cancelling a job.

Phaedrux

@icecube45 said in 3.1.1 - BLtouch doesn't function after cancelling a job.:

M558 P9 C"zprobe.in+zprobe.mod" H5 F120 T12000 A10 S0.018

Not sure if this will help, but modify this command to be:

M558 P9 C"^zprobe.in" H5 F120 T12000 A10 S0.018 R0.5

icecube45

@Phaedrux said in 3.1.1 - BLtouch doesn't function after cancelling a job.:

Not sure if this will help, but modify this command to be:
M558 P9 C"^zprobe.in" H5 F120 T12000 A10 S0.018 R0.5

I don't think recovery time would help, being as mesh probing/repeated probing works correctly.
I will try it when I get some free time anyhow.

If it helps, here are oscope traces from before and after cancelling a print, and sending the "pin down" command.
First trace results in pin down, second does not.
Looks like possible noise being introduced after a cancelled job? really unsure.
I should note that I don't remember this behavior occurring before updating to RRF 3.

Before Cancel.png
After Cancel.png

Phaedrux

The main thing was removing the probe mod pin and adding the pullup resistor enable, but recovery/settle time is a good idea for the bltouch anyway.

Do you have a cancel.g in /sys?

Are the motors being disabled or going idle?

icecube45

@Phaedrux Oh sorry, I thought I had said. No I don't have a cancel.g

The bltouch doesn't work with motors idle or active when in this state - I discovered this after starting a new print and having my hotend crash into my build plate.

Will check the mod pin thing when I have a chance. Though I should note that's what the config tool spat out to me when I selected a bltouch.

Phaedrux

Yes the config tool has the mod pin selected by default. It's on the list to change. Only analogue probes that require modulation use it.

Can you try creating a cancel.g file? Either blank or with some sort of commands on what to do after cancelling.

Here's mine as example

; cancel.g
;
; Run when the print is paused, and then canceled.
;

G10 P0 R0 S0		; Set hotend temp to 0
M140 S0			; Set bed temp to 0
M106 S255 		; Fan at 100 to cool nozzle and bed
M220 S100		; Set speed factor back to 100% in case it was changed
M221 S100		; Set extrusion factor back to 100% in case it was changed
M290 R0 S0 ; clear babystepping
M204 P1000 T4000	; Set printing and travel accelerations
M566 X900 Y900 Z30 	; Set maximum instantaneous speed changes (mm/min) (Jerk)
G28 XY			; home XY
M98 P"0:/sys/CurrentsNormal.g" ; return motor currents to normal
M98 P"0:/sys/ZSpeedsNormal.g" ; return Z axis speeds to normal
M84			; turn off steppers
G4 S60			; wait 1 minute for nozzle to cool
M107			; turn off the fan
M98 P"0:/macros/Musical Tunes/TwoBits.g" ; play a tune

icecube45

A blank cancel.g and the M558 adjustments result in no change.

Phaedrux

What version of BLtouch is it by the way?

icecube45

@Phaedrux A 3.1, genuine.

dc42

Looks like you have a lot of stepper motor noise in your system. How have you connected the BLTouch to the Duet WiFi, in particular the two ground wires?

icecube45

Both ground wires are connected as described by the z-probe setup guide

But your comment on stepper noise had me thinking:
"If it's stepper noise, why does it only occur after cancelling a print, and not when I'm swinging the effector around beforehand"

Which led me to the root cause of my issue, my extruder stepper. Specifically (I guess), the hold current.

I tested this with manual control. BlTouch pin down, up. Works great.

Extrude 1mm, command BLTouch, no result.

Issue a M18 E0, bltouch immediately follows the last command sent.

So looks like my extruder stepper is the noisy one. This makes sense, following wire routing.

For now I guess I'll just issue a M18 within my cancel.g.

Unsure what would have caused this to only act up starting with RRF 3.1.1 - perhaps the configurator has a higher default extruder current than it did the last time I ran it?

kodzianin

@icecube45 Wow, i recently had this problem after switching from duet 2 to duet 3 mini 5+ and M18 E0 before homing worked like a charm, i think this problem might come from different TMC drivers and their switching frequency.

Thank you for sharing this solution.