Awesome work Mental, with the probe, and with cleaning up my config from the macro’s. Thank you 😊

If anyone is going to try this branch, I suggest reading the documentation and making sure you understand it as well as keeping a hand on the estop when first trying things.

First off: awesome thing

But it's not clear from doc what state of pins(probe_sense_pin and dock_sense_pin) is expected, for exception of check_open_attach - it's self describing

i've tried to enable manual_verify but detach_probe and attach_probe commands always raises errors twice, for some reason, also i've tried to combine check_open_attach and dock_sense_pin, but it always fails on detach_probe, not sure is it hardware failure or this options are mutually exclusive? it was hardware

btw: i'm testing it on Voron V2.4 with annex probe

UPD: called detach_probe when toolhead was above probe dock and script didn't move toolhead out, instead it decided to drop toolhead right on it

But it's not clear from doc what state of pins(probe_sense_pin and dock_sense_pin) is expected, for exception of check_open_attach - it's self describing

I think I can probably clarify that a bit in the docs. Basically you want the pins to be configured in printer.cfgso they report the correct states when GET_PROBE_STATUS is called.

I've tried to enable manual_verify but detach_probe and attach_probe commands always raises errors twice, for some reason

I will look at how those exceptions are being raised... what frontend are you using?

UPD: called detach_probe when toolhead was above probe dock and script didn't move toolhead out, instead it decided to drop toolhead right on it

If the tool is within the minimum safe distance it will not move away from the dock as that could potentially yank the probe out of the dock. Instead it calculates an intercept vector perpendicular to the approach angle and moves along that and then moves to the dock coordinates. If the tool is already over top of the dock coordinates, the calculations for that probably net to zero tool movement.

I will look at how those exceptions are being raised... what frontend are you using?

i'm running fluidd

I think I can probably clarify that a bit in the docs. Basically you want the pins to be configured in printer.cfgso they report the correct states when GET_PROBE_STATUS is called.

at some point i've inverted dock and it's started to work properly, so when probe is docked expected state is TRIGGERED - that's kind of counter-intuitive, at least for me

If the tool is within the minimum safe distance it will not move away from the dock as that could potentially yank the probe out of the dock. Instead it calculates an intercept vector perpendicular to the approach angle and moves along that and then moves to the dock coordinates. If the tool is already over top of the dock coordinates, the calculations for that probably net to zero tool movement.

Well if i'd call attach_probe this sounds reasonable, but i've called detach_probe and as a result - dock has been destroyed :)

i'm running fluidd

I have noticed that fluidd duplicates error messages being raised in certain cases.

22:30:50
// Klipper state: Ready
22:30:51
!! Error on 'SET_LED LED=ring RED=0 GREEN=1 BLUE=0 INDEX=0 TRANSMIT=1': INDEX must have minimum of 1
22:30:51
!! Error on 'SET_LED LED=ring RED=0 GREEN=1 BLUE=0 INDEX=0 TRANSMIT=1': INDEX must have minimum of 1

I don't know for sure the cause of it, but the exceptions I am raising in the probe module are printer.command_error() messages which should halt execution of the current running command.

at some point i've inverted dock and it's started to work properly, so when probe is docked expected state is TRIGGERED - that's kind of counter-intuitive, at least for me

Internally, I am treating the probe_sense_pin and dock_sense_pin like endstops. It is exceedingly difficult to make a state handler with 3 separate pins that is reliable, which is why only check_open_attach or probe_sense_pin should be used. Additionally, the probe_sense_pin should, in theory, be more reliable than check_open_attach.

If only check_open_attach is in use, the checks follow this logic

if  open_attach = OPEN   then probe_state = ATTACHED
if  open_attach = TRIGGERED then probe_state = DOCKED

When probe_sense_pin is supplied, it follows the same

if  probe_sense = TRUE  then probe_state = ATTACHED
if  probe_sense = FALSE then probe_state = DOCKED

when dock_sense_pin is used in conjunction with either check_open_attach or probe_sense_pin

if  probe_sense = TRUE  and dock_sense = FALSE then probe_state = ATTACHED
if  probe_sense = FALSE and dock_sense = TRUE  then probe_state = DOCKED
if  probe_sense = FALSE and dock_sense = FALSE then probe_state = UNKNOWN
if  probe_sense = TRUE  and dock_sense = TRUE  then probe_state = DOCKED

The TRUE/FALSE part is where the confusion is probably occurring. The pin definition determines how TRUE/FALSE/HIGH/LOW is being reported from the sense pins. So if the pin is defined with ! it will be expecting the "switch" to be in a LOW state in order to report true. So for instance, if you are using the annex probe with the screws through the switch body and a bit of wire connecting them... Assuming that one magnet goes directly to an IO pin and the other magnet is wired into a GND pin... The definition for the pin should be something like ^!P1.25.

Therefor when the probe is not in the dock, the pin reads high, when the pin is in the dock, the pin reads LOW. I probably said that backwards somewhere and my answer is totally wrong because I get confused by this stuff too most of the time.

The reason I included the GET_PROBE_STATUS gcode command was so that this could be more easily debugged when configuring it.

Do you think it would be helpful to include additional information in the output?

Presently it outputs

Probe Status: UNKNOWN|ATTACHED|DOCKED

I could have it include (if the pins are configured

check_open_attach: ATTACHED|UNATTACHED
probe_sense_pin: ATTACHED|UNATTACHED
dock_sens_pin: DOCKED|UNDOCKED

Well if i'd call attach_probe this sounds reasonable, but i've called detach_probe and as a result - dock has been destroyed :)
Could you provide your config file so I can understand what is happening here? I am assuming the dock is mounted to one of the bed support extrusions on the 2.4 in the rear, correct?

If you are using a bed mounted dock, the Z axis should always be homed before attempting to do anything with the probe and the module should be throwing an error if it isn't. It is possible it is trying to Z hop or something because the probe is registering that it is ATTACHED since it is sitting over it in the dock.

I am thinking I need to try to replicate this behavior on my own and add an additional boundary check so that it will not move the Z axis unless it is outside of the minimum safe distance in a sphere around the dock instead of just a radius.

If you are using a bed mounted dock, the Z axis should always be homed before attempting to do anything with the probe and the module should be throwing an error if it isn't. It is possible it is trying to Z hop or something because the probe is registering that it is ATTACHED since it is sitting over it in the dock.

let me clarify:

1. Everything homed, qgl'ed, etc
2. Probe dock is mounted near bed(you've got it right)
3. Toolhead is right above dock, but not touching it
4. Probe is mounted on toolhead and probe status is 'attached'
5. After calling detach_probe toolhead does not bother to move out of dock safe distance and goes down right on it, only by doing z movement, which leads to collision

The TRUE/FALSE part is where the confusion is probably occurring. The pin definition determines how TRUE/FALSE/HIGH/LOW is being reported from the sense pins. So if the pin is defined with ! it will be expecting the "switch" to be in a LOW state in order to report true. So for instance, if you are using the annex probe with the screws through the switch body and a bit of wire connecting them... Assuming that one magnet goes directly to an IO pin and the other magnet is wired into a GND pin... The definition for the pin should be something like ^!P1.25.

As i said, i've got it after some time :) Yet it would be good to have this clarification in docs, something like: if your dock pin is closed when probe is docked, than you need to invert pin

The reason I included the GET_PROBE_STATUS gcode command was so that this could be more easily debugged when configuring it.

Unfortunately get_probe_status does not give clear visibility what exactly happens to pins, with clarify of pins states in doc it should not be a problem ofc w/o it it's kinda not clear is it hardware failure or wrong configuration(i could move probe by hands so it's become 'detected' with wrongly configured pin, but i didn't actually seen is it shorted dock pins or not)

As additional suggestion: it would be good to have an option to disable 'return to previous position' after attach/detach action(at least as command argument) since in a lot of cases it's just makes unnecessary movements

Ok. I think it would be overall beneficial for me to add individual pin states in for the GET_PROBE_STATUS command for debugging purposes. I will look into the positioning after detach is called. It might need some adjusting.

Thanks. This does seem like useful functionality. Alas, I haven't gotten a chance to fully review it and I think it will be weeks before I can review it.

Some comments from my limited review:

1. I can't tell if "annexed" is meant to be related to the physical hardware or is a reference to the 3d printer community. In either case, I think a different name would be preferable. Perhaps something like "probe_dock".
2. As high-level feedback, I fear this module/documentation may be too "generic" - in that it's customizability may limit its utility for real-world users. Specifically, I fear the configuration complexity may be too great for users to configure it optimally. If possible, I think selecting one or two common dock designs and coding/documenting for them may help. Also, if there are config options that are "optimization" it may help to eliminate them for simpler use. (For example, is it necessary to define a dock_angle and dock_safe_distance as opposed to defining a rendezvous coordinate that the toolhead always moves to on dock and undock?)
3. I'd be leery of having the probe "auto attach". Could we just require the user run ATTACH_PROBE prior to any probing attempts, and require them to run DETACH_PROBE when complete? (And, raise an error if the user issues any "probe" command when the probe is not actually attached.)

Thanks again,
-Kevin

Thanks. This does seem like useful functionality. Alas, I haven't gotten a chance to fully review it and I think it will be weeks before I can review it.

It is not at all ready for merge so no rush. I opened the PR primarily so people could test it and to elicit feedback from the community.

I can't tell if "annexed" is meant to be related to the physical hardware or is a reference to the 3d printer community. In either case, I think a different name would be preferable. Perhaps something like "probe_dock".

It's a bit of both actually. The dictionary definition for annexed is
attached or added, especially to something larger or more important
I will be more than happy to rename it.

As high-level feedback, I fear this module/documentation may be too "generic" - in that it's customizability may limit its utility for real-world users. Specifically, I fear the configuration complexity may be too great for users to configure it optimally.

The "default" configuration requires the following values be set

pin:
z_offset:
sample_retract_dist:
dock_position:
dock_angle:
detach_angle:
dock_safe_distance:
check_open_attach:
dock_fixed_z:

dock_position, dock_angle, detach_angle, and dock_safe_distance must be supplied. detach_angle could be inferred using a perpendicular vector to the dock_angle by default, but it would need to be able to be specified in the even that it guesses incorrectly. Additionally a dock_safe_distance of 50mm could be defaulted as well. These vectors could also easily be obtained via coordinates instead of angles. So a user could supply departure_position, dock_position, and approach_position instead.

The two distinct positions for approach and departure must be used in most cases so a single rendezvous point would not be ideal. In most cases lifting the toolhead away from the probe can, over time, pull the magnets out of their pockets and this results in probe accuracy degrading. To properly remove the probe from the toolhead, the probe is "slid" off the magnets in a side to side motion. If a single rendezvous point is used, the probe would never actually detach.

sample_retract_dist must be supplied as well due to the switch actuation and attachment checks. During most probing routines the calling module will retract the toolhead after the probe is triggered. Certain modules leave the toolhead down after the probing move and the switch remains triggered. Due to how many of these switches are wired, this falsely reports that the probe is detached when it is not. I have added a check after probing moves that ensures the toolhead is at or above the sample_retract_dist so that this does not occur. It could be defaulted to 3mm since most probes use a variation of the omron switch with around a 2mm actuation distance.

It would also be possible to remove check_open_attach as a config option and leave it on by default. In the event someone defines probe_sense_pin it is already switching detection to use the pin instead.

If possible, I think selecting one or two common dock designs and coding/documenting for them may help. Also, if there are config options that are "optimization" it may help to eliminate them for simpler use. (For example, is it necessary to define a dock_angle and dock_safe_distance as opposed to defining a rendezvous coordinate that the toolhead always moves to on dock and undock?)

I can look into further scaling back the supported conditions. I initially did a survey of users to find out what and how they were using the probe. 68% of respondents said their dock was mounted to a moving gantry or to the frame with the remainder having bed mounted docks. I felt that limiting it only to moving gantries, however, limited it to "cube" printers so I included bed mounted docks as well.

By my count there are 3 popular designs floating around, the Annex Quickdraw, the Voron Users Klicky-Probe, and the Euclid. These all use a variation of the same basic dock and probe design using magnets and a "fork", so the built in default toolhead movements were intended to handle those. The biggest difference between the 3 is the length of the forks on the dock which translates to the dock_safe_distance parameter.

The mounting locations of these varies and I have limited support for them to positive Z positions. It is not feasible to "dip" the toolhead into negative space to pick up the probe.

Outside of the dock, the only other common condition that affects operation is whether or not the probe is being used as an endstop or if a physical endstop is in use.

So without doing any custom gcode options the "default" common dock configurations (dock_fixed_z) :

• Gantry/Frame mounted
• Z Positive Bed mounted with separate Z endstop

The 6 optional gcode sections that can be supplied exist for users with edge cases. There are a few printers with odd pathing issues that cannot be solved with straight lines so they need to be moved to a position prior to moving to the approach so fan ducts don't get ripped off etc... The other use case is to have the dock on a servo that flips it into position. I have heard that there are people wanting to build this type of dock for Switchwire printers but I have not seen it yet. I figured I would go ahead and add something so they can deploy the servo at the appropriate time. They are in there as config options but should not cause.

I use these sections to change the color of the LEDs on the toolhead to reflect the current probe action.

I'd be leery of having the probe "auto attach". Could we just require the user run ATTACH_PROBE prior to any probing attempts, and require them to run DETACH_PROBE when complete? (And, raise an error if the user issues any "probe" command when the probe is not actually attached.)

As for the auto attach part. The goal was to have it behave like any other probe in that you command 'probe' from the gcode console and a complete probing action occurs without having to write macros around it. I have not noticed any adverse behavior with the automatic attach part, only the auto detach part. The adverse behavior reported so far is typically due to false positives with probe detection or user configuration. Even if it were made to only attach and detach when commanded, I believe it would still exhibit the same behavior since it would read the probe state incorrectly.

In the case of probe calibration for instance, I believe it would cause out if DETATCH_PROBE was called from the terminal after the initial point was probed. At the present time, when PROBE_CALIBRATE is called, the probe is picked up, the first point is probed, the probe is docked, and the toolhead returns to the calibration point for the nozzle.

I am likely removing the delayed_detach entirely as it only seems to cause problems if DETACH_PROBE is not explicitly called at the end of a "start print" gcode sequence.

I also waffled around for days about whether or not I wanted to support scenarios where there was no internal means of probe detection and the user supplies the probe state via the gcode command. I think this is just going to cause more trouble that it is worth as well so it is probably going away as well. I think in order to use the module, there must be some way configured to determine the probe state.

The two distinct positions for approach and departure must be used in most cases so a single rendezvous point would not be ideal.

Okay, that makes sense.

68% of respondents said their dock was mounted to a moving gantry or to the frame with the remainder having bed mounted docks. I felt that limiting it only to moving gantries, however, limited it to "cube" printers so I included bed mounted docks as well.

Okay, FWIW, I think it may be easier to target the main use case first, get the code merged, get lots of feedback, and then look to extend to other probes (if necessary).

The biggest difference between the 3 is the length of the forks on the dock which translates to the dock_safe_distance parameter.

I'm a little confused on what dock_safe_distance is used for. Wouldn't we always want to dock from the same dock_rendezvous_coordinate and undock to the same undock_rendezvous_coordinate?

The goal was to have it behave like any other probe in that you command 'probe' from the gcode console and a complete probing action occurs without having to write macros around it.

So, as high-level feedback, we tried to do something similar in Klipper with the toolchange commands (eg, T1). That is, the code tried to do the "right thing" and there was config customizability to handle "corner cases". It didn't work well, as the config complexity to "do the right thing" was far greater than the config complexity of a macro that explicitly states the steps it takes.

FWIW, I expect users of a "docked probes" to introduce macros for their calibration routines (eg, G29) and I expect that they will do that regardless of how "smart" the dock code is. It shouldn't be difficult to add an explicit ATTACH_PROBE command to these macros, and I suspect being explicit will actually make the macro more clear. Having some of the actions in a G29 macro, some in the code, some in [annexed_probe] config section, etc. I fear will be harder to understand.

I also waffled around for days about whether or not I wanted to support scenarios where there was no internal means of probe detection and the user supplies the probe state via the gcode command. I think this is just going to cause more trouble that it is worth as well so it is probably going away as well. I think in order to use the module, there must be some way configured to determine the probe state.

That makes sense to me. Again, it's always possible to add additional features at a later time.

Thanks,
-Kevin

FWIW, I expect users of a "docked probes" to introduce macros for their calibration routines (eg, G29) and I expect that they will do that regardless of how "smart" the dock code is. It shouldn't be difficult to add an explicit ATTACH_PROBE command to these macros, and I suspect being explicit will actually make the macro more clear. Having some of the actions in a G29 macro, some in the code, some in [annexed_probe] config section, etc. I fear will be harder to understand.

Well, if code is smart enough it will dock probe whatever happens, at the same time if user does not have proper error handling in gcode(let’s be honest-it’s quite complex question) than he will face issues with probe attached in situations where it not expected to be on toolhead

Indeed, I have my dock at Xmax and Ymax position. Currently I gave up and wrote hard-coded macro, that work flawlessly along with tricky home procedure, preventing probe to be dropped off the head. Looiking forward for this awesome work to be completed and merged into mail klipper code already :)

It has also come to my attention that running this in Python 3 has some issues. So far I have identified an incompatibility on line 187 where it is trying to parse the coordinates out from the config file. In python 3 the map function needs to be converted to a list first. I am told this is not particularly efficient but it only has to execute once when the config is loaded.

    def parseCoord(name, c=3):
            try:
                p = [None] * 3
                val = config.get(name, None)
                if not val:
                    return None
                p[0:c] = list(map(lambda x: float(x.strip()),
                             val.split(',')))[0:c]
            except:
                e = "Unable to parse {0} in {1}"
                raise config.error(e.format(self.name, name))
            return p

What's the status on this PR and its level of completion? I am willing to help if needed. This has been something I feel that a TON of klipper users have been using for a long time, and having to keep pulling in main/master to their local clones of this fork.

I guess TL;DR -- what's holding up the PR merge and can I assist at all?

what's holding up the PR merge
-- I am busy and lazy
and can I assist at all?
-- Yes.

Read the comments, make the changes, submit a PR to my repo and I will merge.

@mental405 this might have already been addressed, but what's the behavior when a probing fails? (samples exceed tolerance, etc) -- will this dock the probe afterwards?

Hello! I'm just wondering why this hasn't been merged yet. I'm looking at Mental's PR and the files changed, and everything seems to be in order. Is there something I'm not seeing? Having to have a separate "BED_MESH_CALIBRATE" macro just to define more macros to move to the dock area is giving me a lot of headaches right now, and I feel like now a module for stuff like this is a requirement.

This still needs to be merged. Any updates?

To everybody having:
TypeError: initializer for ctype 'struct trdispatch_mcu *' must be a cdata pointer, not NoneType
Just add:
self.printer.register_event_handler('klippy:mcu_identify', self._handle_mcu_identify)
between
self.printer.register_event_handler('klippy:ready', self._handle_ready)
and
self.printer.register_event_handler('homing:home_rails_begin', self._handle_homing_rails_begin)
It'd look like this:

        self.printer.register_event_handler('klippy:ready',
                                            self._handle_ready)
        self.printer.register_event_handler('klippy:mcu_identify',
                                            self._build_config)
        self.printer.register_event_handler('homing:home_rails_begin',
                                            self._handle_homing_rails_begin)

It error'ed because couldn't find the method, so I checked probe.py and the method is in the class ProbeEndStopWrapper.
I just added the method manually to dockable_probe.py:

    def _handle_mcu_identify(self):
        kin = self.printer.lookup_object('toolhead').get_kinematics()
        for stepper in kin.get_steppers():
            if stepper.is_active_axis('z'):
                self.add_stepper(stepper)

Probably not the best approach, but it works now.

This PR was inadvertently closed due to a regression introduced by #6293.

-Kevin

What is the status of this PR? I wonder if we should track this on Klipper Discourse instead of on github?

-Kevin

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.