Detachable Probes and Probing

T3P3Tony

@sinned6915 can you summarise the issue? Is it that deploy and retract macros are not being run for G30 but they are for G29?

dc42

@sinned6915 if you have the probe type set to anything other than 9 (which is for BLTouch) then the behaviour is as follows:

M401 and M402 increment and decrement the probe deployment count. When M401 causes the deployment count to go from 0 to 1, RRF executes deployprobe.g. When M402 causes it to go from 1 to 0, RRF executes retractprobe.g.
At the start of executing G29 S1, RRF implicitly executes M401. At the end, it implicitly executes M402.
When executing G30, RRF implicitly executes M401 before and M402 after.

Therefore:

When using single G30 command to home Z, the probe will be deployed and retracted automatically
When executing G29 S1 the probe will be deployed and retracted automatically
Within a bed.g file that contains multiple G30 commands, when using a deployable probe it is best to use M401 before the first G30 command and M402 after the last one. That way, the probe will be deployed and retracted just once for the entire sequence, instead of once per G30 command.

sinned6915

dc42: thank you for answering the question. Knowing that there is a probe deplyment counter is the key I was missing.

If I may suggest that your succinct explanation get added to G29 & G30 or M401/M402 wiki entries.

Which now got me to thinking to check the Object Model for the token- I dont see anything for probe deplyment. I see

sensors.probes.0.deplyedByUser=true

and

sensors.probes0.value=1000

but no deployment count. Any idea what that might be stored as?
I am thinking it might be more reliable to use that instead of theraw probe data.

sinned6915

@dc42 I think I have noticed a pattern that may highlight the probe pickp/retract issue. I am using Duet3 Ethernet, RRF version 3.2.2

Case 1: Printer is homed. Probe is detached. Carraige is at X,Y of 100,100
Issue G30 S-1 command to perform a single probe. The expectation is probe will occur at 100,100.
Printer will execute M401 and sucessfuly deply the probe EXCEPT that instead of probing the original position of 100,100, it will execute the probe at the final positiion of the deployprobe.g macro.

Expectation is that the printer would have returned to the position (100,100) to perform the probe.

Case 2: Priner is homed, Probe is detached.
Issue M401 P0 command, printer picks up the probe.
G1 move to the point 100,100 and then issue
G30 S-1
and it executes the single probe at the point.

EDIT- Case 3 Printer is homed, Probe is detached
Issue G30 X100 Y100 S-1 command, priner will sucessfuly deply the probe and will execute the probe at the final positiion of the deployprobe.g macro instead of the X100 Y100 coordinate.

Bothe cases: issuing M402 P0 errors and reports back probe is not present.
Which is because of my gcode metal logic of sensing the presence of the probe via the probe's actual value of 0 or 1000 (open circuit vs closed vircuit).
As the machine stops Z motion at the probe trigger, the probe is still triggered, NC having gone open.
Moving the Z away from the probe will reset the probe back to the NC state and then the M402 script will execute.

Phaedrux

I wonder if you could use G60 to store the location and then use G1 R to restore to that location.

https://duet3d.dozuki.com/Wiki/Gcode#Section_G60_Save_current_position_to_slot
https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_G0_G1_Move

sinned6915

@phaedrux you could, but that seems like that would not be nescessary.

The wiki says that if the G30 -S1 command is issued without X or Y coordinates, the probe would occur at that point. To me, that means it will probe the X,Y where the command was issued.

I could just issue a G30 X100 Y100 S-1 but that is different than giving the G30 by itself. I don't remember the results of that offhand and have to redo it when the machine is not in use.

The system realizes that if there is no probe attached, it goes to deploy it. The G30 then seems to occur when the moves of the deploy macro are complete. It has forgotten the starting point.

EDIT: I updated the case of giving a G30 with coordiantes to the original post.

sinned6915

@dc42 @T3P3Tony I am pretty certain that something is up with the deploy and retract scheme. The system does not realize that the probe is picked up, even though it has sucessfully picked up the probe.

The approach that I am trying to used is to change the probe pin inversion and do homing moves instead of using one probe type and incremental moves.
Can you answer these questions and offer any guidance?

Does changing the probe pin inversion reset the probe pickup state?
What is the token in the object model that represents the probe deployment state? I can not tell from the OM Browser. Screen snip at the end.

Here is a video of my machine tying to deploy the probe using a G1 move command instead of a controlled incremental move. And for good measure, the macros and config in a zip file if you want to delve deeper.

Console & Machine video

Firmware files

Here is the commented deployprobe.g file that is running in the video.

; ***********************************************************
; deployprobe.g
; config.g is M558 K0 P8 C"^zprobe.in" H10 R0.5 F240:120 T9000 A3 S0.03
; ***********************************************************
echo "Running deployprobe.g"
echo "Reset Probe to NC"
M558 K0 P8 C"^zprobe.in" H10 R0.5 F240:120 T9000 A3 S0.03

G91
M564 H0 S0          ; allow movement while not homed
G1 Z17 F6000        ; move Z 15 for clearance above dock.
                    ; need to figure out some safety check on this
G90 
echo "First logic check"
echo  "Probe State Value" ^sensors.probes[0].value[0]
if sensors.probes[0].value[0]!=1000    ; if sensor is value other than 1000 do this
  abort "deployprobe start value Probe already picked up.  Manually return probe to the dock"
;  echo sensors.probes[0].value[0]
; if we're here we know it's becasue the above is true which I assume is because you have an NC switch as a probe.
echo "Pass first logic test"

echo "Move to doc"
G1 X0.0 Y-27 F6000      ; move above probe dock location
G91
G1 Z-10
G90
M400                ; wait for moves to finish
echo "Redefine probe type" 
M558 K0 P8 C"^!zprobe.in" H10 R0.5 F240:120 T9000 A3 S0.03
echo "M558 Inverted"
G4 S1

echo "Probe Pickup while loop running"
; while sensors.probes[0].value[0]=1000
echo  "Probe State Value" ^sensors.probes[0].value[0]
while sensors.probes[0].value[0]=0
  G91
  ; G1 Z-0.5 F600
  ; was controled move in previous scheme
  G1 Z-100 H1 F300
  ; move in -Z to trigger endstop via G1 H1 
  M400
  G90
  ; echo sensors.probes[0].value[0]
  ; echo iterations
  ; if iterations=100
  ;    break
echo "Probe Pickup while loop complete"

G91                 ; relative coords
G1 Z-0.5 F600       ; move bed up 0.5 to clear probe from dock since mags pull it up 
M400                ; wait for move to finish
G90
G1 X50 F3000        ; move right so probe moves out of the dock
M400
G1 Z12 F3000         ; move bed to clear probe from glass build surface 
G1 X100 F6000       ;
G90                 ; absolute coords
M400                ; wait for moves to finish
G4 S2               ; wait 1 second
echo  "Probe State Value " ^sensors.probes[0].value[0]
echo "Restore probe type"
M558 K0 P8 C"^zprobe.in" H10 R0.5 F240:120 T9000 A3 S0.03
echo  "Probe State Value " ^sensors.probes[0].value[0]
M400
G4 S2 

echo "Last Logic Check"
echo  "Probe State " ^sensors.probes[0].value[0]
if sensors.probes[0].value[0]!=0
   abort "Abort deployprobe endvalue not 0 Probe not picked up!  Print cancelled."

echo "deployprobe.g complete"

dc42

@sinned6915 said in Detachable Probes and Probing:

I am pretty certain that something is up with the deploy and retract scheme. The system does not realize that the probe is picked up, even though it has sucessfully picked up the probe.

How are you commanding the probe to be picked up? The system should realise it is picked up if and only if you use M401 to pick it up.

sinned6915

@dc42 I am explicitly calling M401 to deploy the probe in the homez.g file. Line 13 of the homez.g file

it's already picked up and in position when the G30 command in issued in the bed.g file (4 point leveling, 3 Z screws).

The error message that the system reports from the gcode meta command comes from the M401 file.

If you watch the youtube video, you will see the console messages with the carriage movements.
Console & Machine Video - https://www.youtube.com/watch?v=0A3sT0sjbHs

You can see where in the homez.g macro, where the pritner has has picked up the probe and successfully completed M401, it returns and calls the bed.g macro. Taht is where the M401 is called again and i errs out becasue the probe is already picked up.

; ***********************************************************
; homez.g
; ***********************************************************
if !move.axes[0].homed || !move.axes[1].homed     ; If the printer hasn't been homed, home it
   M98 P"0:/sys/homexy.g"  
M561                                            ; clear any bed transform
M290 S0 R0                                      ; clear baby steps per Wes C
G91                                             ; relative positioning
M400
; G1 H2 Z6 F6000                                ; lift Z relative to current position
G90                                             ; absolute positioning
echo "Call deployprobe.g macro" 
M401 P0                                         ; This runs macro file deployprobe
echo "returned from deployprobe.g"
echo "Go to center of bed & probe"
G1 X145 Y162.5 F3000                            ; go to bed center
M400
; echo "Perform G30 S-2 Command"
; G30                                           ; Probe the bed at the current XY position. When the probe is triggered, 
                                                ; adjust the Z offset of the current tool to make the current position Z=0.
echo "Perform G1 Z-10 H1 Command"
G1 Z-10 H1                                      ; Move and terminate the move when the endstop switch is triggered and set the axis position to 
echo "Perform G92 Z2.6 Command"
G92 Z2.6                                        ; Set the Z axis to the probe offset height  

M400
G91                                             ; Relative Coordinates
G1 Z1 F6000
M400
G90                                             ; Absolute Coordinates
G1 Z10 F6000
M400
G4 P500
echo "Call bed4point.g macro"
M98 P"0:/sys/bed4point.g"                       ; tram bed
;
echo "Return from 4-point macro"
echo "Re-probe to set Z incase it drifted"
G1 X145 Y165 F9000                              ; go back to the first probe point and reprobe 0 in case it moved
G30
echo "Call retractprobe.g macro"
M402 P0                                         ; retract probe
echo "Return from M402"
G1 Z10 F600                                     ; lift Z relative to current position
G90                                             ; absolute positioning
M564 S1 H0
; G1 X150 Y0 F9000                              ; move carraige to center front

jay_s_uk

@sinned6915 use conditional gcode in the bed file to check whether the probe has already been picked up or not.
sensors.probes[0].deployedByUser
that object should do it for you.
so something like

if sensors.probes[0].deployedByUser == 0
   M401

sinned6915

@jay_s_uk ok, i will try using that as a token to report the status.

i could not tell what that token was telling me.

dc42

@sinned6915 said in Detachable Probes and Probing:

The error message that the system reports from the gcode meta command comes from the M401 file.

What error message? I didn't see an error message in your video.

sinned6915

@dc42: i am sorry if i mis-spoke.

I wrote the echo comment to read

abort "deployprobe start value Probe already picked up. Manually return probe to the dock"

Bottom line, I can not determine why the system seems to loose track of the probe pickup token.

Do you have any ideas? Can you offer any help?

I have been fighitng this for weeks, months really if you go back to my other thread on trying to pick up the probe from the bed.