BLTouch doesn't always deploy Duet 3 6HC
Having an intermittent issue where the bltouch doesn't always deploy. The light stays red, and the nozzle crashes. It's a new build and the cables seem to be well connected. I am trying to narrow down a way to replicate it, but having trouble figuring out a process to do so. Anyone else having an issue? I'm on RRF 3.2 Final.
Remove the pin and clean it. There is a set screw on the top of the probe. Remove it and the pin can be slid out. Sometimes they get little wisps of filament stuck to the pin.
@Phaedrux I have done that, but this issue seems to behave a little differently. For one, the bltouch should send an error code when the probe doesn't deploy. Second. Usually when you probe the bed, the probe will deploy and the led will turn off.
When the probe isn't deploying the light remains red which on other printers i have, sends an error that the probe was already triggered before the homing move started. That behavior makes me believe the issue is not a wisp of filament but firmware related.
Please post your config.g, homeall.g, deploy and retract macros.
Post the results of M122 and M98 P"config.g"
What version of BLtouch? How exactly is it wired? Photos?
@Phaedrux It's wired just like the official duet wiki on the subject. You'll see from my config.g what port. It's the bltouch v3.1. M98 P"config.g" gives me a warning that my bed heater is overpowered.
; Configuration file for Duet 3 (firmware version 3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.2.1 on Sat Jan 09 2021 15:21:32 GMT-0500 (Eastern Standard Time) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"Duet 3" ; set printer name M669 K1 ; select CoreXY mode ; Drives M569 P0.0 S0 ; physical drive 0.0 goes backwards M569 P0.1 S1 ; physical drive 0.1 goes forwards M569 P0.2 S1 ; physical drive 0.2 goes forwards M569 P0.3 S0 ; physical drive 0.3 goes backwards M569 P0.4 S1 ; physical drive 0.4 goes forwards M569 P0.5 S0 ; physical drive 0.5 goes backwards M569 P1.0 S1 ; physical drive 1.0 goes forwards M584 X0.1 Y0.0 Z0.2:0.3:0.4:0.5 E1.0 ; set drive mapping M671 X-50:-50:350:350 Y0:375:375:0 S3 ; Z Lead Screw Leveling probe Point Mapping M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation M92 X160.00 Y160.00 Z400.00 E415.00 ; set steps per mm M566 X720.00 Y720.00 Z30.00 E3000.00 ; set maximum instantaneous speed changes (mm/min) M203 X14400.00 Y14400.00 Z720.00 E4000.00 ; set maximum speeds (mm/min) M201 X3000.00 Y3000.00 Z200.00 E4000.00 ; set accelerations (mm/s^2) M906 X1200 Y1200 Z1200 E700 I40 ; set motor currents (mA)and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X300 Y300 Z250 S0 ; set axis maxima ; Endstops M574 X1 S3 ; configure sensorless endstop for low end on X M574 Y1 S3 ; configure sensorless endstop for low end on Y M574 Z1 S2 ; configure Z-probe endstop for low end on Z M915 X Y S3 F0 R0 H400 ; configure stall detection for X and Y sensorless homing ; Z-Probe M950 S0 C"io7.out" ; create servo pin 0 for BLTouch M558 P9 C"^io7.in" H3 F340 T14400 ; set Z probe type to bltouch and the dive height + speeds G31 P500 X0 Y21 Z2.73 ; set Z probe trigger value, offset and trigger height M557 X20:280 Y30:270 P4 ; Define mesh grid ; Bed Heater M308 S0 P"temp0" Y"thermistor" T100000 B3950 ; configure sensor 0 as thermistor on pin temp0 M950 H0 C"out0" T0 ; create bed heater output on out0 and map it to sensor 0 M307 H0 B0 S0.6 ; disable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S120 ; set temperature limit for heater 0 to 120C ; Nozzle Heater M308 S1 P"1.temp0" Y"thermistor" T500000 B4723 C1.19622e-7 ; configure sensor 1 as thermistor on pin 1.temp0 M950 H1 C"1.out0" T1 ; create nozzle heater output on 1.out0 and map it to sensor 1 M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit M143 H1 S280 ; set temperature limit for heater 1 to 280C ; Fans M950 F0 C"0.out4" Q10 ; create fan 0 on pin out4 and set its frequency M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off M950 F1 C"0.out5" Q10 ; create fan 1 on pin out5 and set its frequency M106 P1 S0.6 H1 T45 ; set fan 1 value. Thermostatic control is turned on ; Case Fans M950 F2 C"0.out7" Q10 ; create fan 2 on pin out7 and set its frequency M106 P2 S0.4 C"Case Fan 1" M950 F3 C"0.out8" Q10 M106 P3 S0.4 C"Case Fan 2" M950 F4 C"0.out9" Q10 M106 P4 S0 C"Exhaust Fan" ; Tools M563 P0 S"Extruder" 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 are not defined ; Miscellaneous ;M575 P1 S1 B57600 ; enable support for PanelDue M501 ; load saved parameters from non-volatile memory T0 ; select first tool
; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool v3.2.1 on Sat Jan 09 2021 15:21:33 GMT-0500 (Eastern Standard Time) G29 S2 ; disable bed mesh compensation G91 ; relative positioning M400 ; make sure everything has stopped before we make changes M913 Z30 ; Z motors to 30% current G1 Z10 F300 H2 ; drop bed Z relative to current position M400 M913 Z100 ; Z motors to 100% current M280 P0 S160 ; Reset bltouch in case it didn't have vertical clearance for self test. G90 ; abs positioning ; Home X G91 ; relative positioning M400 M913 X25 Y25 ; XY motors to 25% current G1 H1 X-310 F4000 ; move until motors hit X min and stall G1 X20 F3000 ; go back a few mm on X M400 M913 X100 Y100 ; XY motors to 100% current G90 ; abs positioning G1 X150 F10000 ; Home Y G91 ; relative positioning M400 M913 X25 Y25 ; XY motors to 25% current G1 H1 Y-320 F4000 ; move until motors hit Y min and stall G1 Y20 F3000 ; go back a few mm on Y M400 M913 X100 Y100 ; XY motors to 100% current G90 ; abs positioning ; Home Z M400 G90 ; absolute positioning G1 X150 Y129 F6000 ; go to probing point (between two Z rods, 30mm bltouch offset) M400 G30 ; Probe and home Z (pass 1)
m122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956BA-NA3TJ-6J1F4-3SJ6T-KVAUV Used output buffers: 5 of 40 (10 max) === RTOS === Static ram: 149788 Dynamic ram: 62864 of which 76 recycled Never used RAM 146104, free system stack 126 words Tasks: Linux(ready,101) HEAT(blocked,271) CanReceiv(blocked,809) CanSender(blocked,352) CanClock(blocked,352) TMC(blocked,53) MAIN(running,1217) IDLE(ready,19) Owned mutexes: HTTP(MAIN) === Platform === Last reset 03:43:01 ago, cause: software Last software reset at 2021-02-03 12:20, reason: User, none spinning, available RAM 146104, slot 2 Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Aux1 errors 0,0,0 MCU temperature: min 34.3, current 38.5, max 38.8 Supply voltage: min 23.8, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Driver 0: position 44640, standstill, reads 32548, writes 28 timeouts 0, SG min/max 0/1023 Driver 1: position 3360, standstill, reads 32548, writes 28 timeouts 0, SG min/max 0/1023 Driver 2: position 22292, standstill, reads 32553, writes 23 timeouts 0, SG min/max 0/259 Driver 3: position 0, standstill, reads 32553, writes 23 timeouts 0, SG min/max 0/206 Driver 4: position 0, standstill, reads 32553, writes 23 timeouts 0, SG min/max 0/190 Driver 5: position 0, standstill, reads 32553, writes 23 timeouts 0, SG min/max 0/172 Date/time: 2021-02-03 16:03:57 Slowest loop: 159.64ms; fastest: 0.04ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 13040273ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 13, completed moves 13, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], 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 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === 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. === CAN === Messages queued 53530, send timeouts 0, received 107075, lost 0, longest wait 1ms for reply type 6042, free buffers 48 === SBC interface === State: 4, failed transfers: 0 Last transfer: 3ms ago RX/TX seq numbers: 27671/27671 SPI underruns 0, overruns 0 Number of disconnects: 0, IAP RAM available 0x2c8a8 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 36.36 Maximum length of RX/TX data transfers: 2912/784
Is it failing to deploy during homeall, or when doing a G29? Or both?
Try adding a small delay after deploying the probe. The simplest way is to use the R parameter in the M558 command. 0.1 sec should be sufficient.
Remove the ^ in front of the pin name in the M558 command. It's only needed on Duet 2 when using the Z probe input pin or expansion connector pins. Using it on Duet 3 reduces the noise margin.
ctilley79 last edited by ctilley79
It seems to be random. Sometimes it's home all, sometimes it's during my bed level routine. Seems to happen more if the machine has been idle for a while, or after a change in config.g. The odd thing is when i catch it and quickly halt the machine, the next time around it works flawlessly.
@dc42 I'll try adding a delay and see if that helps.
EDIT: Adding a delay did not help. Edited the config and saved., ran homeall after the machine came back up, and probe did not deploy. E stopped the machine and tried again. Probe deployed. at a loss here.
User3D last edited by User3D
@ctilley79 My BL-Touch used to go in blink state too ,So I've this line to change its mode to ALARM RELEASE in my config at the end and even at start and end of bed.g . Try this I suppose.
For deployment problem I would suggest you to increase dive height that is H parameter's value in M558 which is 3 right now. Mine is 8.
Try a slower dive speed as well. The Bltouch likes it slow. Try F120.
Dive height should be a bit more than the trigger height. 2.7 and 3 is pretty tight. Try H5.
How long of a delay did you add with the R parameter? Try R0.5
@User3D It's not going into blink state though. the led is staying solid like it never got the signal to deploy. The bltouch is not erroring out. The next time around though it works.
That sounds like an intermittent signal issue. May be worth replacing the entire servo signal cable and crimped ends.
@Phaedrux I was afraid you were going to say that
You could try doing a stress test. Create a macro file with M401 and M402 commands separated by a short G4 S1 pause and have it repeat that many times. See if it can reliable deploy and retract while still. Then try adding some movement commands in between to move the head around while deploying and retracting.
@Phaedrux I like that better. will report back
ctilley79 last edited by ctilley79
@Phaedrux Ok. I ran this macro inside a 100 iteration loop a few times while jostling the cable bundle around and the probe worked flawlessly. The dive height you mentioned I see where you're coming from, but let's say my Z axis is at Z130 and I home all. I raise the gantry by a little bit, home x, y, then probe the bed, the probe doesn't deploy even at that height. It's not like it doesn't have enough time to deploy.
Do you have another BLtouch to test with?
@Phaedrux Not a spare one. Hell, if I have to take this apart I'll use one of the Super Pindas I recently snagged. It's nice being able to probe the actual surface, but I love the fact inductive probes have no moving parts.
@dc42 Ok. I might have some way of repeating this. I left the machine idle for a few hours and ran the below macro. It executed the entire loop and the probe did NOT deploy or retract. Not even once. Using DWC I hit the emergency stop. As soon as the machine came back up I played the macro and the file executed all iterations successfully. It seems this could be related to the machine being idle and no longer being able to send the signal over the io port. I don't think this is a cable or connector issue due to the fact that the machine did not move an inch before or after hitting the estop.
while iterations < 20 echo iterations G4 S1.0 M401 G4 S0.5 M402 continue
I suspect that If the firmware thought the probe was already deployed at the start. RRF remembers whether M401 has been used to deploy the probe, and only sends the deploy command if the probe is not recorded as having been deployed. If you send several M401 commands without an intervening M402 command, RRF counts how many M401 commands you sent, and only retracts the probe when you have sent the corresponding number of M402 commands. This is to allow M401 and M402 commands to be used in nested macro files
One consequence of this is that if the probe enters an error state, as well as resetting the error you should send M402 a couple of times to ensure that RRF knows that the probe is retracted.
However, none of this is relevant to G29 probing failing if you have set the probe type to 9 in M558, because for probe type 9 the deploy and retract files are sent every time a point is probed.
@dc42 Ok. I think I may have ruled out the bltouch as being faulty. I just finished a print and let the machine idle for about an hour and the machine would not respond to m402 or m401 commands. Even sending multiple m402 before m401 commands did not help. I also tried M280 P0 S160 to reset the bltouch. The machine was in a homed state and I can manually jog the axis, however If I were to have hit home all, I know the probe would not have deployed.
So what I did was unplugged the bltouch power wires at the extruder. When I restored power, the bltouch went through its startup sequence deploying and retracting twice. I then tried to deploy the probe with M401 and nothing happened. So the bltouch was in a fresh state but the Duet 3 was not. So I e-stopped the machine to restore the duet 3 to a fresh state and the probe worked flawlessly. Should I try a different I/O port?
Can try io4 or io5.
SneakyTiki last edited by SneakyTiki
I have a very similar problem, but much easier to replicate, and on different hardware and firmware.
BLTouch will work and deploy flawlessly when I first power on the machine. But as soon as I have used it in a macro (so if I do a G30, or I run a macro to square my gantry, or I run a bed mesh) it will stop responding to commands.
So it will do G30, it will do G29, but only once per power-cycle, and per macro. As a test, I modified my home z to home ( I have a limit switch), probe by my lead screws to tram the gantry, g30 in the middle of the bed, and then G29 to mesh the bed. All of this completes flawlessly. But will only do it once. After it is done, probe doe snot respond to any M280 commands, M401 or M402 commands, nothing. And the blue PWM signal light on it is now out until power-cycle.
I cannot do what I described if I break up the sequence. So if I make a macro to just tram the gantry, I cannot do any of the rest afterwards.
I tried what was recommended earlier, and when on a fresh power-cycle, it will seemingly respond to M280 and M401 and M402 commands indefinitely (I literally pasted thousands of them into a macro and went to lunch, it was still working when I came back)
I wish I could tell you if this is some new behavior, but I have just purchased the BLTouch, and was setting it up for the first time
Oh, it's a BLTouch v3.1
I have it wired through the probe connection.
Configured as follows:
M558 P9 H5 F240 T5000 A4 S0.005 R0.2 B1 ;BLTouch probe (p9), h = dive height, f=z speed, t=travel speed, A=max # of times to probe, s=deviation allowed, r=recovery time, b1=turn off heaters
G31 X-43 Y-5 Z2.102 P25 ;Define the X,Y,Z-offsets of the probe,P=trigger value (25 for BLTouch)
Duet Meastro 1.0, Firmware 2.05.1 (2020-02-09b1)
Is it the case for both of you that once you have run G29, you can no longer deploy the probe by running M401 ? Or is there something else you need to do after running G29 before M401 stops working?
SneakyTiki last edited by SneakyTiki
@dc42 I sure am glad you asked the question, and I went to confirm before replying.
Clearly I had jumped to some conclusions when first attempting to narrow down the problem and provided an inaccurate report. Here's an update:
Neither G29 nor G30 seem to 'bug' the sensor. Putting them into a macro which simply runs G29, a G0 move, then a G30, also does not 'bug' the sensor.
So I dug deeper and found the cause (at least of my issue, do not want to speak to the problem @ctilley79 has)
My issue was caused by a macro I had which called bed settings after performing things like homing functions, etc.
I went through the commands one by one and found the culprit. It is the M558 command.
For whatever reason, calling M558 P9 (I checked each of the other parameters individually, it's only the P parameter) at any point after the initial power-on reading of config settings, leads to the probe ceasing to respond until power cycle.
Thanks dc42, your pertinent question resolved my problem : D
Time to go fix the macros.