Detecting Z-Probe Pickup on move command

[OwenD]

You shouldn't have the moves to pick up the probe in deployprobe.g
I believe the intent of deployprobe.g is to extend the probe such as when a bltouch or servo probe is used.
As stated above, it is called internally at the start of G30.
If you're manually calling deployprobe.g using M98 and later using G30, then it would do it twice.
Move all that code to say "pickup-probe.g" and likewise put the code to dock the probe into say "dock-probe.g"

[fcwilt]

@sinned6915

I got to thinking about your homeZ.g file.

You call M401 which invokes deployprobe.g.

Later you call G30 - which normally would call M401 but it seems to notice that M401 has already been called and does not call M401 again. It also does not call M402 as it normally would

Later still you call M402 which invokes retractprobe.g.

Are you invoking deployprobe.g directly using M98 somewhere? G30 does not notice that and invokes M401 calling deployprobe.g as it normally would.

Frederick

[dc42]

You might want to configure two separate Z probes, one for the real probe and one for the pickup mechanism. RRF3.2 supports this. They can have each have their own deploy and retract files.

[sinned6915]

@OwenD said in Detecting Z-Probe Pickup on move command:

You shouldn't have the moves to pick up the probe in deployprobe.g
I believe the intent of deployprobe.g is to extend the probe such as when a bltouch or servo probe is used.

That is where I started conceiving this approach. Does the machine really care what it does during the deployprobe?

As stated above, it is called internally at the start of G30.

Any idea where can I confirm this? I'm not distrusting you, I want to re-learn it and maybe re-write the approach I am using.

When I call homez.g, the routine is to pick up the probe via M400, probe Z in the middle of the bed, then probe the 4 corners and level the bed (basically 4-G30 commands, 3 indep motors), then re-probe Z.
The switch is already attached and it does not try to re-deploy the switch.

If you're manually calling deployprobe.g using M98 and later using G30, then it would do it twice.
I'm using M401 and M402 to deploy and retract the probe.

Move all that code to say "pickup-probe.g" and likewise put the code to dock the probe into say "dock-probe.g"

; ***********************************************************
; bed4point.g
; ***********************************************************
 G90
 G30 P0 X0.0 Y5.0 F9000.0 Z-99999       ; probe front left
 G30 P1 X0.0 Y275.0 F9000.0 Z-99999     ; probe back left
 G30 P2 X270.0 Y275.0 F9000.0 Z-99999   ; probe back right
 G30 P3 X270.0 Y5.0 F9000.0 Z-99999 S3  ; probe near front right leadscrew and calibrate 3 motors

[fcwilt]

@sinned6915 said in Detecting Z-Probe Pickup on move command:

That is where I started conceiving this approach. Does the machine really care what it does during the deployprobe?

You are using deployprobe.g correctly in that the code in that file needs to get the probe ready for use by G29 or G30.

Some probes, like Inductive devices, generally are fixed in position and need no deployment. Others, like the BLTouch and yours need to be "deployed" to be ready to use.

Any idea where can I confirm this? I'm not distrusting you, I want to re-learn it and maybe re-write the approach I am using.

Oddly enough I don't see any mention of G30 calling M401 or M402 - but it does as I have verified many times.

In the M558 command docs there is this:

All Z probes use the same deployprobe.g and retractprobe.g files

---

Aside to @Phaedrux: Could you check the docs to see where mention of the calling of M401 and M402 might needed to be added? Thanks.

---

When I call homez.g, the routine is to pick up the probe via M400, probe Z in the middle of the bed, then probe the 4 corners and level the bed (basically 4-G30 commands, 3 indep motors), then re-probe Z.
The switch is already attached and it does not try to re-deploy the switch.

Well in your homeZ.g file you called M401 and M402 explicitly and as I mentioned before when you do that G30 doesn't call them.

You could comment out M401 and M402 in your homeZ.g file and you should still see that deployprobe.g is called.

Do you have a retractprobe.g file?

If you want to verify for yourself what G30 does in regards to these two files you can do what I did.

My deployprobe.g file had this: M291 R"DEPLOYPROBE.G" P"DEPLOYPROBE.G" T1

My repractprobe.g file had this: M291 R"RETRACTPROBE.G" P"RETRACTPROBE.G" T1

So whenever G30 invoked (via M401 and M402) them I could see the message popup on the DWC.

---

So is your homeZ.g file now working?

Frederick

[sinned6915]

@dc42 can I ask you to help me take a step back and re-think this? The solution is becoming unweildly and in my experience, when things get this complex, its probably because I've overlooked something, or I have completely uderestimated it.

The concept is to use a magnetically coupled microswitch as Z probe and endstop. When attached the NC swtich competes the circuit. When detached, its open. It seems simple enough to accomplish.

Considering @OwenD comments, does the switch attachement fall under the scope of probe deployment and retraction? The definition of deployprobe.g is just that its a macro. I read that as 'a bunch of gcode'.

Previously with a fixed dock, the switch attachement was accomplished by simply swiping the carraige clockwise or anti-clockwise through a dock fixed in X,Y,Z location. gcode meta commands allowed me to check the probe value to ensure probe pickup, dropoff or malfunction.

Now I am trying to translate to X,Y and then move in Z.
Once at X,Y location, using a G1 H1 in deployprobe to pick up the switch works but causes issues in the subsequent G30 commands. Add to this the redefinition of the probe high or low and redefining the meta commands to interpret the probe values when switching from high or low.

Using a G30 command at the proper X,Y location to couple the switch, the bed moves away from the carraige, similalry to trying to issue a move command when Z is not homed.

So here I sit, realizing the mirage on the horizon is much longer walk for a small drink of water wondering if there is an oaisis that I have overlooked?

[fcwilt]

@sinned6915 said in Detecting Z-Probe Pickup on move command:

Using a G30 command at the proper X,Y location to couple the switch, the bed moves away from the carraige,

Is the G30 command moving towards Z min or Z max?

Try as I might I cannot G30 to NOT move the bed toward the gantry.

Frederick

[OwenD]

@sinned6915 said in Detecting Z-Probe Pickup on move command:

@dc42 can I ask you to help me take a step back and re-think this?
<snip>

Considering @OwenD comments, does the switch attachement fall under the scope of probe deployment and retraction? The definition of deployprobe.g is just that its a macro. I read that as 'a bunch of gcode'.

@sinned6915
My suggestion was in reference to you saying that the code was running twice.
The file is indeed just a bunch of code, but it can be called implicitly by you and also internally during the execution of another GCode or process.

Likewise, at the beginning of this thread I suggested that a G1 H* move should achieve what you want if configured correctly.
My modification of your loop code was provided based on your findings that G1 H* didn't work for you.

@dc42 stated above you can configure two probes on your tool.
That would seem to me to be a good solution given you want the probe to function as both an end stop and a probe.

I'll withdraw from this thread to reduce the static as the new information provided changes the way I'd go about it.

[sinned6915]

@OwenD I was not calling you out on anything- in fact I am grateful that you offered a reaonable explaination to what I was seeing.

I see nothing in the documentation that says issuing a G30 command to probe will execute a deployprobe. Regardless, that is exactly what appears to be happening. Curiously, After I issue the singe G30, I call on the 4 point beld probing/leveling routine. It follows in sucession without retracting the probe.

I think this basically a catch22- I can not pick up the probe with a G1 H1 move command without changing the probe type and that breaks things downstream. I can not do a G30 command withing the deployprobe macro.

The cleanest way seems to be to do it with the while loop withing the deploy probe macro.
Again, I thank you for helping me underdstand that.

[fcwilt]

@sinned6915 said in Detecting Z-Probe Pickup on move command:
Hi,

I'm still not sure why it is not doing what you want.

I can not pick up the probe with a G1 H1 move command without changing the probe type and that breaks things downstream.

That I do not understand at all as a G1 H1 command has nothing to do with probes.

G1 H1 commands work with endstops, G30 commands work with probes.

In your deployprobe.g that you posted you have this...

G1 H1 Z-280 F300    ; controlled linear move up the height of build envelope
                    ; H1 terminate the move when the endstop switch is triggered
                    ; and set the axis position to the axis limit defined by M208 

but I cannot find where you configure that endstop.

I can not do a G30 command withing the deployprobe macro.

No you cannot but again I cannot see why you need to.

As I understand it:

• You are trying to pickup the bottom half from a "dock".

• Once you do that you will have a functioning Z probe.

• You are trying to have the move stop with you have "coupled" with the bottom half.

Is that correct so far?

If it is tell me this - at the moment the bottom half is "coupled" is the switch in the bottom half ON or OFF.

Or to ask another way when the bottom half is in the "dock" is the switch ON or OFF.

I'm still trying to understand why you need to reconfigure the probe.

Thanks.

Frederick

[dc42]

You can have different deploy and retract files for different Z probes. Name them deployprobe0.g for Z probe 0, deployprobe1.g for Z probe 1, and so on. Similarly for the retraction files. If the file that includes the Z probe number isn't found then it falls back to the regular deployprobe.g and retractprobe.g files.