Detachable Probes and Probing
-
@o_lampe no, the IR probe was fixed.
What difference does it make if the probe is detachable or not?
RRF seems to know that it needs to pick up the probe, I just can not figure out the logic yet.
If its a BL Touch, it seems to know to deploy the probe.
-
@sinned6915
In some cases the configurator tool adds two macros in the /sys folder:
deployprobe and retractprobe.
If you find them, take a look inside. Maybe it explains your probing issues? -
@o_lampe those macros are there and funcitonal.
my question is how RRF determines if the probe is picked up or not.
-
I don't think it has any way of knowing if it's picked up or not. If deploy and retract macros are present they will get executed blindly.
What do you have in your deploy and retract macros?
What is the probe?
How does it "pick it up"?
-
@phaedrux It's a magnetically coupled Z probe with snap action switch in NC mode (config'g with pullup). Here is a abridged video of the general operation-
probe deployment (via M401 P0) ,
homing the at the center,
start of 3 point leveling,
final probing at the end of leveleing,
and probe retraction (via M402).EDIT: why is my link missing?
https://youtu.be/HiKOW4jA3oU
YouTube VideoAgain, I am trying to understand the proper way that RRF would probe a single point, a la G30 or G30 S1.
I do not believe that I have to explicitly issue a probe deploy and retract command. I thought that it would do it automatically upon G30 command. That goes not seem to be the case.
I am also wondering how it might function with G38 commands. I can imagine that a 1D/2D/3D probe be on a toolhead and be used similarly.
Here are the relavent lines form my config.g-
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 G31 K0 P500 X-16.4 Y-29.27 Z2.95 ; for snap action switches DF2 etc
sinneD
-
What do you actually have in deployprobe.g and retractprobe.g?
G30 will probe the current position. So you'd need to position the probe in XY first.
@sinned6915 said in Detachable Probes and Probing:
I do not believe that I have to explicitly issue a probe deploy and retract command. I thought that it would do it automatically upon G30 command. That goes not seem to be the case.
It does for the BLtouch because it has a dedicated probe type for it's usage. There are no other common probe types that require deploy and retract, so I'm not actually sure if it's going to be automatic if the deploy and retract files are present. It may very well be required to issue M401 and M402 before/after the G30.
-
@phaedrux said in Detachable Probes and Probing:
I'm not actually sure if it's going to be automatic if the deploy and retract files are present. I
I remember, embarassing myself with a long rant about G30 giving me heart stitches, when it turned out that it does execute the deploy/retract macros. I had an 'Allen Key' switch on another printer, which neede to be deployed and retracted.
It wasn't on RRF3.x but v2.05...did it change?
@sinned6915
easy test would be to add anecho "deployprobe started"
in the macro.
-
@o_lampe said in Detachable Probes and Probing:
It wasn't on RRF3.x but v2.05...did it change?
I think it checks to see if they are present and if so will execute them. There have been cases where the files are present when they should not be and deleting them solves a probing problem. So I believe that's the case.
-
@sinned6915 I guess the other question is when you want to pick up/put down the probe. I think that the deploy/retract scripts are called for every probe dive (so doing a 400 point mesh, it will pick up, probe, put down, pick up, probe, put down etc 400 times!). A BLTouch pin needs to be extended for every probe dive, whilst yours probably doesn't.
You might be better putting your own pick up/ put down macros and calling them explicitly in your homing, bed leveling, mesh creation etc macros? -
EDIT: why is my link missing in the previous post? I'l chalk it up to lack of sleep.... video of deply and retract. The following probaly makes more sense now....
EDIT2: I put all my configs and files on github instead of pasteting it all here-
RRF3.x sys folder@phaedrux I was hoping to not get into the nitty gritty, but here goes.
I have explicit deploy and retract scripts and call them in my homez.g and homeall.g scrips. they work there just fine.
if i issue a G29 command, then the bot will pick up the probe and probe the mesh sequetially w/o returnging the probe between point. It runs the whole mesh then returns the probe.
The deploy probe is conditional gcode. Since i am picking it up from a fixed X,Y but variable Z position I have it doing some gymnastics. I do have comment codes in the macros to track its progress.
The probe deploy flow chart is basically:
- after homing X & Y,
- move Z 15,
- translate to dock position in X,Y,
- move Z -10,
- while loop starts
-move Z incrementally -0.5,
-check probe status. if probe value is 1000, repeat, - if probe value is not 1000, exit while loop.
; *********************************************************** ; deployprobe.g ; *********************************************************** echo "Running deployprobe.g" G91 M564 H0 S0 ; allow movement while not homed G1 Z15 F6000 ; move Z 15 for clearance above dock. ; need to figure out some safety check on this G90 ; echo 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" G1 X0.0 Y4 F6000 ; move above probe dock location G91 G1 Z-10 G90 M400 ; wait for moves to finish echo "Probe Pickup while loop running" while sensors.probes[0].value[0]=1000 G91 G1 Z-0.5 F600 M400 G90 ; echo sensors.probes[0].value[0] ; echo iterations if iterations=100 break G91 ; relative coords G1 Z-0.25 F600 ; move bed up to clear probe from dock since mags pull it up M400 ; wait for move to finish G1 X50 F3000 ; move right so probe moves out of the dock G1 Z6.5 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 M400 if sensors.probes[0].value[0]!=0 abort "deployprobe endvalue not 0 Probe not picked up! Print cancelled." echo "deployprobe.g complete"
The probe retract is simpler since the X,Y & are determined-
; *********************************************************** ; ; retractprobe.g ; ; *********************************************************** echo "Running retractprobe.g" if sensors.probes[0].value[0]!= 0 abort "retractprobe: Probe not currently picked up!" echo "pass first logic loop" ; M564 S0 ; allow movement outside of print area G90 ; absolute positioning G1 X100 Y4 Z8.10 F12000 ; move to the starting point G1 X45 Y4 F6000 ; move to the entry position for the dock G1 X0 Y4 F3000 ; move to the dock position G1 X0 Y50 F12000 ; move to the side adjacent to the dock M400 G1 X100 Y50 F12000 ; move to the right to clear dock G1 X145 Y0 F6000 ; move to start point at middle front M400 M564 S1 ; limit axis to print area echo "complete movement commands" if sensors.probes[0].value[0]!= 1000 abort "retractprobe: Probe not correctly dropped off in dock!" echo "retractprobe.g macro complete"
@engikeneer funny you should bring up the allen key probe, that was one of the insprirations to my probe design. sort of 'get it when you need it' that and the semi-automatic constant wired probe for i3's you manualy deplyed.
I migrated from a well working 2.05 setup to 3.x. Granted, I had eveything set up differently 2.x with a fixed probe dock and no logic checks, but doing this in RRF 3 it seems to make a bit more sense and has provided some failsafes in the system.
for clarity, here is an example of one of my probe point macros- teh back left corner specifically.
; ******************************* ; probeBL.g ; Probe Back Left Corner ; ******************************* M561 ; clear all transforms G91 ; relative coords G1 Z5 ; move Z up 5 to ensure clearance G90 ; absolute coords G1 X5 Y280 Z5 F6000 ; move to bacl keft corner G30 S-1 ; probe point report status
-
@o_lampe what was the reasoning to the conclusion for having the deply/retract macros NOT in the system folder?
I am not seening the conclusions in the posts.
-
If you only need to do the pickup and drop off once then it's not exactly a deploy retract situation. Instead of using deploy retract macros, you could use mesh.g and simply add the pickup and drop off there with the G29 S1 in between. Then when you call G29 it will execute mesh.g, pick up the probe, run a mesh, and drop it off.
-
@phaedrux i am not trying to mesh probe.
i am trying to probe the 4 corners and center of the bed. for example, to validate the results of 4 point leveling.
if i do
G1 X5 Y280 Z5 F6000 ; move to back left corner G30 S-1 ; probe point report status
shouldnt the system realize the probe needs to be picked up?
-
@sinned6915 said in Detachable Probes and Probing:
shouldnt the system realize the probe needs to be picked up?
If you add a resistor voltage divider to your dock and connect it to the probe pin, it would read a certain voltage. That tells the FW if the Z-probe is attached or not. (via conditionals)
With the probe attached, your switch would short out one of the resistors and the value changes to 'probe is deployed, but not triggered'Kind of 'three state' switch probe.
-
@sinned6915 can you summarise the issue? Is it that deploy and retract macros are not being run for G30 but they are for G29?
-
@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.
-
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. -
@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. -
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 -
@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.