Euclid probe unnecessary docking

Joeyhershey

I so the issue I'm having is that after the probe does the bed leveling it docks the probe and then goes and picks it back up to do the bed mesh. these wastes time docking and undocking.
How do I stop this? Do i need to add a code into my slicer??
bed.g
mesh.g

A Former User

This post is deleted!

dc42

@Joeyhershey use M401 to deploy the probe at the start of the sequence and M402 to stow it at the end.

A Former User

This post is deleted!

Joeyhershey

@dc42 so do I need to combine the two codes into one with using the M401 &402 code??

Phaedrux

@Joeyhershey said in Euclid probe unnecessary docking:

@dc42 so do I need to combine the two codes into one with using the M401 &402 code??

I'm not sure what you mean, but here is what DC42 is suggesting

M401 ; deploy probe
;;;Euclid Probe;;;
M561 ; clear any bed transform
G30 P0 X10 Y70 Z-99999        ; probe near leadscrew 1
G30 P1 X60 Y120 Z-99999       ; probe near leadscrew 1
G30 P2 X110 Y170 Z-99999      ; probe near leadscrew 1
G30 P3 X160 Y220 Z-99999      ; probe near leadscrew 1
G30 P4 X250 Y475 Z-99999      ; probe near leadscrew 2
G30 P5 X250 Y425 Z-99999      ; probe near leadscrew 2
G30 P6 X250 Y375 Z-99999      ; probe near leadscrew 2
G30 P7 X250 Y325 Z-99999      ; probe near leadscrew 2
G30 P8 X470 Y70 Z-99999       ; probe near leadscrew 3
G30 P9 X420 Y120 Z-99999      ; probe near leadscrew 3
G30 P10 X370 Y170 Z-99999     ; probe near leadscrew 3
G30 P11 X320 Y220 Z-99999 S3  ; probe near leadscrew 3 and calibrate 3 motors
M402 ; dock probe

A Former User

This post is deleted!

dc42

To clarify: RRF keeps track of how many deploy and retract commands have been issued, either explicitly using M401/M402 or implicitly by G29 S0 or G30. If you don't use M401/M402 then every time you command G29 S0 or G30 then RRF will deploy the probe at the start of the command and retract it at the end. However, if you use M401 first then when you use G29 S0 or G30 then RRF knows the probe is already deployed and doesn't deploy and retract it.

So if you want to run both auto calibration or bed tramming AND mesh bed probing, then you should use M401 to deploy the probe, execute the G30 commands for auto calibration or bed tramming, then command G29 S0, and finally M402 to retract the probe. You can do all of this in a single macro as @Herve_Smith suggested.

A Former User

This post is deleted!

dc42

@Herve_Smith said in Euclid probe unnecessary docking:

@dc42 said in Euclid probe unnecessary docking:

To clarify: RRF keeps track of how many deploy and retract commands have been issued

What is the purpose of keeping track of that information ?

So that if e.g. you have a macro that uses M401 and then commands G32, and your bed.g file also uses M401, then the probe won't be retracted when the M402 in bed.g is executed but instead will remain deployed until the M402 in the original macro is executed.

A Former User

This post is deleted!

dc42

@Herve_Smith for the OP's case, if he wants to run a sequence of G30 commands in bed.g and collect/stow the probe just once, he needs to use M401 and M402.

A Former User

This post is deleted!

dc42

@Herve_Smith I guess you haven't used deployprobe.g or retractprobe.g then.

sinned6915

@Joeyhershey did you get this sorted?

It took us a while to figure out the RRF behavior when developing Euclid because this wasn't well documented. The RRF2 & RRF3 examples have comments within then with regards to wrapping the gcodes and macros within M401 and M402 sets.

as dc42 explained, RRF's deploy token is checked internally, you want to be consistent with M401/M402. this advice is based on experience, not opinion.

M401 and M402 are the NIST standard gcodes for probe deploy and retract. At least thay have been the gcodes in reprap for 15 years +/- now. They call the deplyprobe.g and retractprobe.g macros. As dc42 pointed out, the associations are built in, don't rename them.

Looking at your files, you have mixed BLTouch commands and Euclid commands. I recommend that you get rid of all the old BLT stuff. I don't know how BLT works with RRF, but the M280 may be triggering the probe token as well.

you can check with something like this-
echo "Probe Value =" ^sensors.probes[0].value[0]

If you are clever, you can write a conditional gcode that could check for probe delployed or not and have that in your files.

Lastly, you might notice why the Euclid examples do not check the check the OM probe variable for deploy: we check the actual probe value to ensure pickup in case of a mis-deploy.

sinneD

fcwilt

@sinned6915 said in Euclid probe unnecessary docking:

Lastly, you might notice why the Euclid examples do not check the check the OM probe variable for deploy: we check the actual probe value to ensure pickup in case of a mis-deploy.

sinneD

So you have a new version of the probe where the presence/absence of the switch can be detected?

Thanks.

Frederick