Z-probe released with a solenoid

[Marcossf]

Hello everyone again.

Our Z-probe for the specific needs of our machine is "non-standard". A BlTouch does not help us since we need the probe to deploy and stow >30mm.
With Marlin, we used the SOL01 pin to trigger the solenoid pin that releases the probe. This pin connects to an external mosfet that activates or deactivates the solenoid current, dropping the probe or retracting it respectively. We check it with M401 and M402 for deploy and stow respectively.
Then we have a flag on the probe with an opto endstop connected to the pins of Z endstop.
It is a very simple and reliable system that in Marlin with SKR1.4 and other electronics has always worked.
Essentially a bltouch is still a solenoid and an endstop alike.

Now with the Duet 3 6HC we are trying to replicate the solenoid operation, but we have not been able to make the solenoid work with either the M280, M42, or M401 or M402 commands.
The endstop activates correctly on the defined pin, but not the solenoid (tested endstop with M119). The mosfet is connected to gnd +5v and the signal trigger pin (io3.out) , but nothing comes out of that pin. The mosfet doesn't sense anything.

What we have in config.g is:
; Endstops
M574 Z1 S2 ; configure Z-probe endstop for low end on Z

; Z-Probe
M950 S0 C "io3.out" ; create servo pin 0 for BLTouch
M558 P9 C "io3.in" H25 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds
G31 P500 X0 Y0 Z10.5 ; set Z probe trigger value, offset and trigger height
M557 X15: 200 Y15: 195 S20 ; define mesh grid

Possibly a rookie nonsense with RRF and Duet. How can we done it?

Thank you!

[dc42]

@marcossf, if you send M42 P0 S1 then you should get 3.3V on the io3.out pin. If that works then you can put this command in file sys/deployprobe.g.

Is 3.3V enough for the mosfet switch? If it isn't, have you considered driving the solenoid directly from a 12V fan output on the Duet?

BTW if you use a solenoid with that mosfet switch, you should connect a flyback diode in parallel with the solenoid, otherwise the switch is likely to fail eventually.

[Marcossf]

@dc42 Ok, I'll test that this morning. Also I will test with fan pin directly to drive the solenoid as you suggest.

In other boards (Ramps, SKR, MKS...) this mosfet setup worked with 3.3v pin signal.

The z-probe endstop will be placed in the 6HC board, not in the 1XD who drives the Z axis or 1LC in the printhead. ¿Is there any problem for that?

[Marcossf]

Already tested.

The M42 P0 S1 command deploy the probe as expected, so it works. M42 P0 S0 retract it.

I've create the sys/deployprobe.g (M42 P0 S1) and sys/retractprobe.g (M42 P0 S0) files with their respective command inside.

I need to include some additional code in homez.g or homeall.g?
It doesn't deploy when I do either home.

M401 and M402 commands deploy and retract, both OK.

[Marcossf]

@dc42 I think the flyback diode it's already included in the mosfet used as per component schematic:

I think a Schottky diode would be mandatoty if direct driving the solenoid thru the out fan connector pin. True?

[dc42]

@marcossf said in Z-probe released with a solenoid:

I need to include some additional code in homez.g or homeall.g?
It doesn't deploy when I do either home.

It sounds like your Z homing is set up to use an endstop switch, not a Z probe. See https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_Z for how you should home Z using a Z probe.

[dc42]

@marcossf said in Z-probe released with a solenoid:

I think the flyback diode it's already included in the mosfet used as per component schematic:

That's not a flyback diode. A flyback diode is connected in parallel with the solenoid, cathode to positive side, anode to negative side. Its purpose is to catch the back EMF spike produced by the solenoid when the mosfet turns off and dissipate it, mostly in the resistance of the solenoid.

Without it, the back emf will be dissipated by avalanche breakdown of the mosfet. Power mosfets generally have an avalanche energy rating, but the energy stored in a solenoid may exceed this rating.

The Duet fan outputs have flyback diodes built in, except on older Duet WiFi boards.

[Marcossf]

@dc42 The homez.g was generated by RRF config tool selecting zprobe as zhome method.

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Wed Mar 24 2021 10:52:22 GMT+0100 (hora estándar de Europa central)
G91               ; relative positioning
G1 H2 Z5 F6000    ; lift Z relative to current position
G1 H1 Z-105 F1800 ; move Z down until the endstop is triggered
G92 Z0            ; set Z position to axis minimum (you may want to adjust this)

; Uncomment the following lines to lift Z after probing
;G91              ; relative positioning
;G1 Z5 F100       ; lift Z relative to current position
;G90              ; absolute positioning

[dc42]

@marcossf said in Z-probe released with a solenoid:

@dc42 The homez.g was generated by RRF config tool selecting zprobe as zhome method.

When I select Z probe, this is the generated homez.g:

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Wed Apr 21 2021 10:45:13 GMT+0100 (British Summer Time)
G91              ; relative positioning
G1 H2 Z5 F6000   ; lift Z relative to current position
G90              ; absolute positioning
G1 X15 Y15 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 F100      ; lift Z relative to current position
;G90             ; absolute positioning

So I think either you must have made the wrong selection, or there is a bug in the config tool that is getting triggered by some other selection you have made.

[Marcossf]

@dc42 Yes, could been edited in some of the test we did.

When manually trigger the Z endstop the Zaxis homed. Just do not deploy the probe. It is configured as Bltouch.

I have edited it to the default values you posted but the solenoid when Z home still does not activate. Here some configuration is missing, or we have something that we have not seen or understand.

Config.g:

; Endstops
M574 X1 S1 P"!40.io0.in"               ; configure active-high endstop for low end on X via pin !40.io0.in
M574 Y1 S1 P"io0.in"                   ; configure active-high endstop for low end on Y via pin !io0.in
M574 Z1 S2                			 ; configure Z-probe endstop for low end on Z

; Z-Probe
M950 S0 C"io3.out"                      ; create servo pin 0 for BLTouch
M558 P9 C"io3.in" H25 F120 T6000       ; set Z probe type to bltouch and the dive height + speeds
G31 P500 X0 Y0 Z2.5                     ; set Z probe trigger value, offset and trigger height
M557 X15:200 Y15:195 S20                ; define mesh grid

Deployprobe.g:

;Rutina de despliegue de sonda
M42 P0 S1	;despliega la sonda activando el pin P0 en io3.out

Retractprobe.g:

; Rutina para recoger la sonda

M42 P0 S0	;recoge la sonda P0 conectada a io3.out pin

Homez.g

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Wed Mar 24 2021 10:52:22 GMT+0100 (hora estándar de Europa central)
G91              ; relative positioning
G1 H2 Z5 F6000   ; lift Z relative to current position
G90              ; absolute positioning
G1 X15 Y15 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 F100       ; lift Z relative to current position
;G90              ; absolute positioning

[dc42]

@marcossf, please test whether the probe deploys when you send G30 to do a single probe of the bed.

Are you certain you want to use P9 instead of P8 in your M558 command? P9 is intended for BLTouch, and causes the probe to be retracted again immediately it touches the bed. So when probing multiple points or probing a point multiple times, it deploys and retracts once per probe. Whereas with P8 the probe can be deployed just once, and retracted just once.

[Marcossf]

@dc42 Ok, I inmediatelly do that test.

Those test we are doing is simply to see that our autolevel part of the system works. What we really want to do on this machine is more complex, and we still don't quite know how to do it.

The Autolevel just define the tilt or geometry for the print surface for all tools. Each toolhead need to set their X Y offset manually (at this moment) and Z offset automatically.

The printer could have up to three manual switchable printheads (1LC inside each), where each tool one would be different. At least we have planned 10 types of printhead suitables to fit in this machine. Still we don't know how manage the Can ID, nozzle offsets and other doubts still not arisen.

[Marcossf]

Changed P9 by P8 in M558 at config.g. Still not Z homming and no G30

We would try other P options?

[Marcossf]

If I invert the pin and put the P5 option in config.g:
M558 P5 C"!io3.in" H25 F120 T6000
the G30 command deploy the probe without the previous error but the endstop doesn't trigger.

Same behaviour when tried with P8 option: M558 P8 C"!io3.in" H25 F120 T6000

It's like the deployprobe.g and retractprobe.g it is not being obeyed during G28 routine.

[dc42]

@marcossf, the message "Error: Z probe already triggered during probing move" is causing RRF to command the probe to retract as soon as it has deployed. Does your probe report "triggered" whenever it is not deployed? If so, then you need to add a delay to allow the probe to deploy before it is tested. The simplest way is this: in deployprobe.g, after the M42 command add a G4 command to insert a suitable delay. For example, G4 P200 will add a delay of 200ms.

[Marcossf]

@dc42 Ok, we tested with the pause for probe deploy as you suggest.

G30 now deploy the probe, but the endstop doesn't recognize that it is being activated. DWC "see" the activation in the status area, but not trigger it.

Doing HomeZ don't deploy the probe despite the delay. However, M42 or M401/M402 works, but this only demonstrate the sucesfull solenoid pin activation.

I suspect that the problem is in our Z endstop flag that is in it's trigger status when the probe is retracted and stay in this position until the probe is released for the probing at G28, so the Zhome always think is in Z=0.
When the solenoid release the probe, el endstop waits for be triggered again by the flag when its pushed by the probe. Once retracted, the flag back to the endstop active status.

In Marlin, it works because there is a define that use endstops only for homing: home x, home y, deploy probe, trigger Z endstop, retract probe and ignore the endstop status after that. Doesn't matter the Z endstop remain active after probing.
We think Duet are monitoring endstops at all times so no probe deploy or z-endstop are beeb triggered because is already done.

We will prototype a new flag that it release the activated status when the probe is retracted and check if we are right.

[Marcossf]

Ok @dc42 , tested with a probe flag that doesn't activate when the probe is in retracted position. Same behaviour.

The Z endstop is only activated in a small area of probe flag movement (±4mm). When activated by hand it is seen in the status goes from 0 to 1000 so it works ok.

The G30 command obeys the deployprobe.g file by releasing the probe, but it does not detect that the endstop is being activated, while this change is seen in the DWC status, as well as in the LED of the Z endstop.

When doing homeall.g the probe is never deployed. So, it doesn't obey the deployprobe.g file.
However, if I enter the solenoid activation lines before the G30 in homez.g, it doesn't deploy it either, but it does detect the activation of the endstop, stopping the Z axis motor when triggered by hand.

Config.g:

; Endstops
M574 X1 S1 P"!40.io0.in"               ; configure active-high endstop for low end on X via pin !40.io0.in
M574 Y1 S1 P"io0.in"                   ; configure active-high endstop for low end on Y via pin !io0.in
M574 Z1 S2                			 ; configure Z-probe endstop for low end on Z

; Z-Probe
M950 S0 C"io3.out"                      ; create servo pin 0 for solenoid
M558 P8 C"io3.in" H25 F120 T5000       ; set Z probe type to bltouch and the dive height + speeds
G31 P500 X0 Y0 Z2.5                     ; set Z probe trigger value, offset and trigger height
M557 X15:200 Y15:195 S20                ; define mesh grid

Deployprobe.g

;Rutina de despliegue de sonda
M42 P0 S1	;despliega la sonda activando el pin P0 en io3.out
G4 P400		; temporiza la sonda 400ms

Homeall.g

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Wed Mar 24 2021 10:52:22 GMT+0100 (hora estándar de Europa central)
G91                     ; relative positioning
G1 H2 Z5 F6000          ; lift Z relative to current position
G1 H1 X-205 Y-205 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
;G1 H2 X5 Y5 F6000       ; go back a few mm
;G1 H1 X-205 Y-205 F360  ; move slowly to X and Y axis endstops once more (second pass)
G1 H1 Z-105 F360        ; move Z down stopping at the endstop
G90                     ; absolute positioning
G92 Z0                  ; set Z position to axis minimum (you may want to adjust this)

Homez.g:

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Wed Mar 24 2021 10:52:22 GMT+0100 (hora estándar de Europa central)
G91              ; relative positioning
G1 H2 Z1 F6000   ; lift Z relative to current position
G90              ; absolute positioning
G1 X100 Y100 F6000 ; go to first probe point
;M42 P0 S1						;******just for testing******
;G4 P400						;******just for testing******
G30              ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
G91              ; relative positioning
G1 Z5 F100       ; lift Z relative to current position
G90              ; absolute positioning

[dc42]

@marcossf, I plan to test this today using a configuration similar to yours.

[droftarts]

@marcossf To help @dc42 troubleshoot this, please can you send M122 and post the response. This will show firmware version and if you are using SBC, as well as other useful information.

Ian

[Marcossf]

@droftarts @dc42

6HC in standalone mode.

M122 diag:

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2.2 running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956L2-G43S4-6J9F4-3S46N-TU4QD
Used output buffers: 3 of 40 (12 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 92148 of which 608 recycled
Never used RAM 116288, free system stack 181 words
Tasks: NETWORK(ready,197) ETHERNET(blocked,110) HEAT(blocked,356) CanReceiv(blocked,848) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,51) MAIN(running,1119) IDLE(ready,19)
Owned mutexes:
=== Platform ===
Last reset 00:01:12 ago, cause: power up
Last software reset time unknown, reason: MemoryProtectionFault iaccViol, FilamentSensors spinning, available RAM 116360, slot 1
Software reset code 0x416d HFSR 0x00000000 CFSR 0x00000001 ICSR 0x00400804 BFAR 0x00000000 SP 0x2041fd38 Task MAIN Freestk 1756 ok
Stack: 2041fdb4 00000000 00000000 00000000 20427384 0045261b 00000000 000f0000 00000001 00444b2b 2041b928 00000000 2041b928 0045260d 00000000 00000000 40400001 3d99999b 00000000 20429288 00000000 2041dbcc 00000000 a5a5a5a5 0873bbcf a5a5a5a5 a5a5a5a5
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 22.2, current 33.5, max 33.6
Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: position 0, standstill, reads 16779, writes 11 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 16776, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 16777, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 16780, writes 11 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 16780, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 16780, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2021-04-22 10:01:30
Slowest loop: 4.39ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, 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 = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock 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
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.
=== Network ===
Slowest loop: 6.65ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 2 of 8
- Ethernet -
State: active
Error counts: 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== CAN ===
Messages queued 12, send timeouts 0, received 12, lost 0, longest wait 1ms for reply type 6042, free buffers 48