Z-probe released with a solenoid

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

dc42

Thanks! .....

dc42

@marcossf, please post your complete config.g file too.

Marcossf

@dc42 Keep in mind that it is a test bed for functionality, not the final printer. There are tons of things to define, add and configure.

Config.g file:

; Configuration file for Duet 3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Fri Mar 26 2021 17:48:23 GMT+0100 (hora estándar de Europa central)

; General preferences
M552 S1									; activa la configuracion de red ethernet
G90                                     ; send absolute coordinates...
M83                                     ; ...but relative extruder moves
M550 P"Duet 3"                          ; set printer name
G4 S1   								;wait for expansion boards to start

; Drives
M569 P40.0 S1                          ; physical drive 0.0 goes forwards
M569 P0.1 S1                            ; physical drive 0.1 goes forwards
M569 P0.2 S1                            ; physical drive 0.2 goes forwards
M569 P121.0 S1                          ; physical drive 121.0 goes forwards
M584 X40.0 Y0.1 Z121.0 E0.2             ; set drive mapping
M350 X1 Y16 Z16 E16 I1                 ; configure microstepping with interpolation
M92 X86.00 Y80.00 Z400.00 E420.00       ; set steps per mm
M566 X900.00 Y900.00 Z60.00 E120.00     ; set maximum instantaneous speed changes (mm/min)
M203 X24000.00 Y6000.00 Z180.00 E1200.00 ; set maximum speeds (mm/min)
M201 X1500.00 Y500.00 Z20.00 E250.00     ; set accelerations (mm/s^2)
M906 Y1000 Z800 E1000	                ; set motor currents (mA)
M84 S0                                  ; Disable motor idle current reduction

; Axis Limits
M208 X0 Y0 Z0 S1                        ; set axis minima
M208 X200 Y200 Z100 S0                  ; set axis maxima

; 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

; Heaters	

; Fans

; Tools
M563 P0 D0 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

dc42

@marcossf, thanks.

I've just tried a configuration similar to your, and it is working for me. I have connected a LED to io3.out to simulate your solenoid. When i execute a single G30 command, the LED lights up, then goes out when I trigger the probe.

I am running the 3.3beta3 candidate firmware. Therefore it is possible that there is a bug in the 3.2.2 firmware that you are running, which is already fixed. Please try the 3.3beta firmware when we release it, which we hope will be later today.

Marcossf

@dc42 OK, we will try with the new version and back here for feedback. Thanks!!

dc42

@marcossf, here is one thing that could be confusing you. When you send G30, RRF will only deploy and retract the probe if it thinks it is not already deployed. To tell whether the probe is already deployed, it counts the number of M401 deploy calls that have not been undone by M402. So if you were to send M401 to deploy the probe, then retract it by sending M42 P0 S0 (instead of sending M402), then RRF would think the probe was already deployed, and not deploy it when you send G30.

Marcossf

@dc42 Let me clarify.

G30 command deploy the probe sucesfully BUT despite being activated the endstop (which I can check in the DWC status Z-sensor or in the LED of the endstop itself).
Finally the G30 ends when retract it for timeout? or end of movement.

Error: g30
Error: Z probe was not triggered during probing move

M401 deploy Ok
M402 retract Ok
M42 P0 S1 deploy Ok
M42 P0 S0 retract OK

Any M280 P0 Snnn are ignored.

When Z Home or HomeAll never deploy it.
However, when we do a home, even though it does not deploy the probe, we touch the endsop manually and it activates, which it doesn't do in a G30 command.

Hope explain me better

dc42

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

When Z Home or HomeAll never deploy it.

Do your homeall.g and homez.g files now use G30 commands to home the Z axis, instead of G1 H1 Z moves?

Please post your homez.g and homeall.g files as they are now.

Marcossf

@dc42 Here are the files.

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)

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

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

sinned6915

@dc42 this is similar to my probe issues.
there something in the configurator that creates this.
i am using M401/M402 explicitly to couple the probe as part of my macros.
you have to use conditional gcodes to detemine if the probe is attached.

i was able to use both G1 H moves as well as G30 with the probe when picked up.

relavant config.g lines

M574 Z1 S2                                       ; configure Z-probe endstop for low end on Z

M558 K0 P8 C"^zprobe.in" H10 R0.5 F240 T9000 A3 S0.03  ; set Z probe type to switch and the dive height + speeds.  Probe A times

and

; ***********************************************************
; deployprobe.g
; ***********************************************************
....
if sensors.probes[0].value[0]!=1000    ; if sensor is value other than 1000 do this
  abort "deployprobe value0 Probe already picked up.  Manually return probe to the dock"

; *****
; gcode for deployment
; *****
 
if sensors.probes[0].value[0]!=0
   abort "deployprobe endvalue not 0 Probe not picked up!  Print cancelled."

and homez.g is basically-

M401 P0                                         ; This runs macro file deployprobe
G1 X145 Y162.5 F9000                            ; go to first probe point
M400
G30 -2
M400
G4 P500
M402 P0

Marcossf

@sinned6915 Thank you very much. In our case we need to adapt your code and macros a bit because we do not have to take a sled, but when we do a test we do not lose anything.
The only thing the solenoid does is deploy or hide a probe. Once deployed, it activates an optoendstop by touching the probe to the bed. Simple.

It is quite clear that it is something in the homing files or in the sw configuration we have, since the activation and the hw part is proven to work.

We came from Marlin and RRF its new for us. Simple things like a homing turn into this "jam"

sinned6915

@marcossf i think you need some logic statements in your macros to checks/verify actuation.
my macros work b/c i am checking the conditions of the circuit via probe value.
you could easily add another sensor as an endstop to veify engagment. i dont know if i would use the solenoid trigger as that check, but a seperate sensor.

dc42

@marcossf, from your photo I can't tell which pins of the 5-pin connector the Z probe opto endstop is wired to. Please provide another photo that shows this clearly, perhaps taken from a different angle.

I think you said that G30 does deploy the probe, but triggering the opto endstop does not stop the G30 movement. Is that right? Does the Z probe reading in the web interface jump to 1000 if you trigger it during G30 movement?

Marcossf

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

@marcossf, from your photo I can't tell which pins of the 5-pin connector the Z probe opto endstop is wired to. Please provide another photo that shows this clearly, perhaps taken from a different angle.

I think you said that G30 does deploy the probe, but triggering the opto endstop does not stop the G30 movement. Is that right?

Yes, it is correct.

Does the Z probe reading in the web interface jump to 1000 if you trigger it during G30 movement?

Yes, it is correct.

dc42

@marcossf, thanks. I can now see the problem. Your config.g file includes this line:

M584 X40.0 Y0.1 Z121.0 E0.2             ; set drive mapping

So you are driving the Z axis from an expansion board (I presume a Duet 3 Tool Board) at address 121. However, the firmware limitations document at https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations includes this:

Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.4.

If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.4.

So in order to get this working completely, you will need to connect your Z motor to the main board instead.

However, RRF 3.3beta3 released yesterday already includes some of the changes to remove this limitation. If you upgrade to that release, then a G30 command should stop the Z motor even if it is connected to the tool board.

A remaining issue that is not fixed in 3.3beta3 is that when the Z motor stops during probing, there may be a very slight overshoot due to transmission delay over the CAN bus, and there is no correction for this. This overshoot should not matter when doing a single Z probe e.g. for homing Z; however when doing mesh bed probing, the error will build up with each probe attempt. As a result, the accumulated error may cause an apparent tilt in the Y direction.

We have work in progress to undo any overshoot after probing. Meanwhile, it can be reduced by using a low Z probing speed. When homing Z, you may wish to do a fast G30 command at a high probing speed (M558 F parameter) first, then lift Z a few mm and do another G30 at a low probing speed.

HTH David

Marcossf

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

@marcossf, thanks. I can now see the problem. Your config.g file includes this line:
M584 X40.0 Y0.1 Z121.0 E0.2             ; set drive mapping
So you are driving the Z axis from an expansion board (I presume a Duet 3 Tool Board) at address 121. However, the firmware limitations document at https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations includes this:

Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.4.

OK, you're right, Z motor are in a external board in this model. In this case a 1LC, but all motors in the final printer are closed loop servos controlled each by a 1XD board.

If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.4.

So in order to get this working completely, you will need to connect your Z motor to the main board instead.

However, RRF 3.3beta3 released yesterday already includes some of the changes to remove this limitation. If you upgrade to that release, then a G30 command should stop the Z motor even if it is connected to the tool board.

Ok, I can test with the beta3 today and see if this limitation was gone.

A remaining issue that is not fixed in 3.3beta3 is that when the Z motor stops during probing, there may be a very slight overshoot due to transmission delay over the CAN bus, and there is no correction for this. This overshoot should not matter when doing a single Z probe e.g. for homing Z; however when doing mesh bed probing, the error will build up with each probe attempt. As a result, the accumulated error may cause an apparent tilt in the Y direction.

We have work in progress to undo any overshoot after probing. Meanwhile, it can be reduced by using a low Z probing speed. When homing Z, you may wish to do a fast G30 command at a high probing speed (M558 F parameter) first, then lift Z a few mm and do another G30 at a low probing speed.

Still haven't build the mechanical parts for test it. At this moment all boards and pheriperals are laying on the desk, so i can't do measurements or test with the real axes. We need a minimum capable firmware to put in the machine when the build start.

Another thing we tested is remove the external mosfet and use the fan pins to drive the solenoid as you suggest (tested out4 and out7 connectors so far) and we was unable to do with the out4 pin:

We define the pin:

M950 S0 C"out4"   ; create pin 0 for solenoid out4
M106 P0 I-1		; disable the pin as a fan

Tested it with M42 P0 S1 and the pin doesn't out 12v between out4 and gnd. Tested other pins in this bank as well: v_outlc1 its fixed at 12v out and out4.tach its 0v and doesn't switch when its commanded. I don't know how use this pins.

However, with Out7 pins, it is OK.
I can drive the solenoid, M42 P0 S1 enable it giving the 12v out, M42 P0 S0 disable it BUT leaving the pin with 5v instead 0v. This could destroy the solenoid at long term.
How can i get 12v when on and 0v when off??

Thanks,
Marcos