WARNING: The safe_z_position option is no longer used, please use the standard homing mechanisms if that functionality is required (i.e. safe_z_home, homing_override).
I should mention I’ve tested it and it’s working well for a bed/Z mounted probe. I also walked through the steps as if it was a gantry mounted probe and all looks good there as well. YMMV but please lmk.
Edit: To all who test and run into issues, please drop your klippy.log here, a description of what happened vs what you expected to happen, and a photo/description of where your dock is mounted. Thank you!
Hi could you tell me what have you changed vs Mental’s dockable probe, ie will a existing config work with your rework and what has been fixed improved, I have been using Mental’s for some time and it has been working well for me, some quirks of course but functional none the less.
Is the dockable switch now working could never get that working before?
My desires for doing this have largely been in reducing the complexity and feature set to make it easier to merge into the kipper code base. Some of the config options have been confusing (for myself and others) and the code shows signs of evolution over time without thorough cleanup. Having said that, none of this would be possible without mental’s work, so thank you for that! Lots of credit due mental for the hard work!
Your existing config will largely be compatible but some tweaking will be needed.
I removed several config options, off the top of my head: dock_fixed_z, all custom gcode options, and delayed detach.
dock_fized_z has been replaced by some inference (if a Z value is specified for approach or dock positioning) and an explicit z_hop option.
Custom gcode options were replaced by separating the movements to attach and detach into gcode commands that can be overridden.
The delayed detach feature wasn’t replaced but I took it out in the interest of simplicity. It should either be added as a feature in the future or something similar (e.g. a LOCK_PROBE gcode that sets a variable that prevents detaches until UNLOCK_PROBE is called).
What’s been added is the z_hop option, Z parameters for approach and detach positions, and the movement gcodes. (Writing this I notice I didn’t fully document the z_hop option. I’ll fix that. It functions the same as z_hop on other probes.)
Hope that helps and let me know if you have questions or any issues.
Can you tell me more about what wasn’t working with the dock sensor? Are you talking about the ‘dock_sense_pin’ feature? What was the behavior you’d see?
It was quite some time ago when I was building my Voron 2.4 and I included the dock_sense_pin but from memory it caused error messages when enabled but my memory might serve me wrong. Even tho it is still wired in I just kept it disabled in the config. I hope I will get a chance in a few days to try your rework.
Please let me know if you get a chance to test this, especially if you test the dock_sense_pin. Unfortunately I don’t have a rig with a sensor on the probe or dock to test it myself.
I’ve made a few tweaks and fixed a race condition. The notable changes are:
Added a way for the user to enable/disable auto-attach/detach: klipper/Dockable_Probe.md at work-annex-probe · cloakedcode/klipper · GitHub This effectively replaces the original delayed detach feature and leaves it up to the user to decide when to dock the probe. There’s also the option of leaving the auto-attach/detach completely disabled for those who want full control.
Thanks for reviving this, would love to see this merged. I like the changed which add the query function in particular.
I’m using a gantry attached klicky probe and this fork isn’t working for me, I’m having collisions with the bed when detaching the probe even with a zhop provided. This worked fine before with dock_fixed_z so I’m not sure removing this config was a good idea.
Just wanted to give you some real world testing feedback. I’ll keep using the original branch for now.
I definitely want to hear more about this not working for you. Are you specifying a Z for any of the ‘position’ options? If the dock and toolhead are always on the same Z plane then specifying a Z won’t help as the code will first try to reach that Z location and could cause bed crashes.
Can you provide your config? Also a description of what you’d expect the movements to be vs what happened? A photo of the mount with the toolhead or drawing of where it’s located? All these would help figure out where the bug in the code is. Thank you!
Unfortunately putting the fixed Z option back isn’t a simple tweak because it requires the code to behave quite differently.
Hey @cloakedcode, I tried your module and it worked on the movement section, but for some reason the probe just stopped moving after the second touch to the bed. So, it was like this when asking to home all axis:
Home X
Home Y
Move to probe
Pickup probe
Move to center of the bed
lower and touch once
go back up
lower and touch again
and then it just stopped there. No error message or anything that I could see.
Aside from that, I like the organization and the config cleanup you did, it makes it way easier to understand.
LMK if I can help debug somehow.
Thanks for trying it out and especially for posting here! The feedback is appreciated and the effort hasn’t gone unnoticed. So thank you.
That is definitely unexpected behavior unless the config specified it (a combination of config options might make this happen). Can you upload your klippy.log? It’s possible the code is conflating config options or respecting one in one place but not another. In short, I’m not sure why the probe would auto-attach but then not auto-detach. Your log might shed some light.
If you manually run DETACH_PROBE after the odd behavior, does the probe detach as expected? Do you see this same behavior if you jog the head to the center of the bed and run PROBE?
Hopefully between the two of us and your log (it contains your config as well) we can figure out what’s going on. If I have your config I think I’ll be able to reproduce it on my side. Lastly, what printer are you running this on and is the dock mounted to the gantry or in the bed plane?
Thanks again for letting me know your experience! Looking forward to getting this working for you.
Alan
Edit: I originally asked for the config but the log will be better and contains the config
Hi @cloakedcode did you get to the bottom of @coredump 's issue? As I’ve just redone my whole klipper setup and tried your dockable_probe.py but having the same issue of stopping right after the second z movement, doesn’t even retract. Also the DETACH_PROBE also does nothing(FYI) klippy.log (5.0 MB)
Just another update the DETACH_PROBE doesn’t work because the probe is still activated but as soon as you move the bed away so the probe disactivates the DETACH_PROBE works and the probe is returned to the dock no problem.
Hey @Geeps, thanks very much for the report and the log. The info you provided allowed me to track down the bug and fix it! As you pointed out, because the probe was still triggered the state was considered “docked” – a probe/dock sensor would solve this. The solution I implemented was to move the tool head before docking but only if probing is complete (i.e. not during a bed mesh or other sequence of probes).
WARNING: The safe_z_position option is no longer used, please use the standard homing mechanisms if that functionality is required (i.e. safe_z_home, homing_override).
Try the latest code there and let me know how you get on.
Morning @cloakedcode, I’ll give the code a try, also I had a dock sense connected a while back so will try get it up and running. Then run tests with and without it, then let you know. (might take a couple of day FYI)
Sorry about that, in the time after I posted my first message I changed to use an Euclid probe, so I didn’t had the time to try the current module, specially because the moves for the Euclid need to be a little different (it approaches from the front, then exits to the side, and vice versa to dock)
I will give it a try in the next few weeks tho. Thanks for the work @cloakedcode and @Geeps
Hi @Geeps, great, testing a dock sensor would be fantastic. Alas, I don’t have one to play with. Good luck and don’t hesitate to post if you run into issues! Happy to help in any way I can.
Hi @coredump, this module should work with a Euclid probe.
_Note: If any of the movements the module performs are not compatible or incomplete, you can override the g-codes, as you would BED_MESH_CALIBRATE or any other, to augment the movements to suit your needs.
Let me know if that helps or you have questions. Maybe there’s more to add to the docs to make this clearer?
I am wrong. The current code will not work with a Euclid probe as that type of dock requires: approaching the dock, attaching the probe, and moving to an extraction position. Docking requires the reverse, moving to the extraction position, docking, and then moving to the original approach position. This is different from a Klicky style dock that uses the same approach position for attaching and detaching.
I think the most elegant solution for this is to add an additional gcode command that can be overridden to have a different approach position when detaching the probe, similarly to the existing MOVE_TO_EXTRACT_PROBE gcode. The other piece of the puzzle would be the approach/detach positions being the same but that’s configurable already and could be set to the same coordinates.
@coredump I’ve changed the module to better support more complex scenarios (as compared to a Klicky dock) such as a Euclid probe. I think adding override support is a good compromise to adding direct support for each dock style as there are certainly going to be less common solutions (e.g. a servo that moves the dock into/out of position). See the last positioning example.
I’ve done some more scribbling on the Euclid docs to illustrate the movements adapted for this module:
@cloakedcode to start I implemented my dock sense and tried with the old code and it then seems to function as expected, then changed over to new code (having to remove the safe_z_position) which in effect now doesn’t know at what position to probe so goes close to the X and Y endstops. Will have to try figure out how to change (and if) the homing override to work. If I can ask why did you remove the safe_z_position? Or could you maybe add a “probing_position”. I forgot to save the log file (got very late myside but can regenerate it if needed…let me know)
Aside from the homing position being off, is the probe behaving correctly with attaching and detaching?
I removed the homing override option as it prevented the user from making use of other homing config sections and it over complicated the code for no gain. The additional code adds maintenance costs and the potential for more bugs/side effects.
The issue for me and possibly others is that I have a homing_override setup in the config already for reducing the XY stepper currents during in homing and you can’t use both at the same time
Going to have to play and test some more…on thinking more I just put the home_xy_position: into the homing_override section just before the Z homing portion and Klipper accepted it so I’ll test this evening when I’m in front of the printer and not remoting in from 80km’s away LOL
Yes, you’re on the right track there. The two config sections can’t be used at the same time but [homing_override] can be tweaked to accomplish the same thing as [safe_z_home].
Looking at your original log file, the [homing_override] section should become something like this:
[homing_override]
gcode =
SET_LED LED=status_leds RED=1.00 GREEN=0.00 BLUE=0.00 TRANSMIT=1
G1 Z10 F400
SET_LED LED=Case_Neo RED=1.0 GREEN=0.00 BLUE=0.00 TRANSMIT=1
SET_LED LED=status_leds RED=0.0 GREEN=0.00 BLUE=0.00 TRANSMIT=1
SENSORLESS_HOME_XY
G1 X150 Y150 # <-- this is the new part
G28 Z
set_position_z = 0
