Requesting detachable Z-probe to be added to the config tool

sinned6915

Hi all-

I'd like to request that an entry be added to the config tool and the dozuki pages for detachable probes under the endstop configuration page.

I am the developer of the Euclid Probe- a probe which is mechanically and electrically coupled through the use of a pair of magnets. The style of probe is gaining in popularity- beyond the installations of Euclid there are a few derivatives of and and imitations of Euclid and it's system.

The probe is essentialy an NC microswitch that is deployed and retracted via the M401 and M402 macros. It can be used as a Z-endstop and as a stand alone Z-probe. In RRF3 Conditional gcode used in the macros for deployment and retraction make the detachable probe robust and reliable. In RRF2, there were no logic checks and the user has to verify attachement or removal.

A corrolary device might be Johan's Allen Key probe that had a few deliberate motions to deply and retract. Those movement steps would need to be user input either by fields in the config tool, or with placeholders in M401/M402 macros to be edited later. Those macros could probably get some extra comments peppered throughout as needed.

I will admit to having some bias towards my own device, but as a class or type of hardware there is certainly a growing following. I'd like to get this catagory/group added to the config tool.

How does a new entry get considered?

What kind of supporting information do we need to provide and maintain?

Thanks in advance

Dennis P.

sinned6915

If anyone is doubting the accuracy or repeatability of such probes, I submit the following bed mesh of a RailCore 300ZL for discussion. This comes from a user who I was helping comission their printer with Duet3 hardware.

I condensed the data into the orange box since the screen aspect ratio was so high and hard to read.

Phaedrux

@sinned6915 said in Requesting detachable Z-probe to be added to the config tool:

How does a new entry get considered?
What kind of supporting information do we need to provide and maintain?

For the wiki an entry can be added by anyone that wants to write it.

For the config tool, it's currently not possible, however the tool itself is going under renovation soon. Can you provide the specific details on what would need to be added to the config files by the tool for configuration? What data fields need to be shown to the user, etc?

fcwilt

@sinned6915

Hi,

I fitted one of my printers with your probe and it works just fine.

Why do you think it needs it own type?

Thanks.

Frederick

A Former User

While I accept & understand the need of a business/person try to make money, when you look at it this product is ridiculously expensive for what it actually is.

Why do you feel the need for a specific entry for this to be added to the config tool ? when you have already stated:

The probe is essentialy an NC microswitch

And a switch is already catered for in the config tool.

Unless im missing something the homing files should/could be written in such a way as to direct the printer to home X &Y then send the tool head to collect the switch from its dock, carry out its task then for it to be returned to its dock, without the need for the M401/402 commands, what more do you need ?

sinned6915

@arnold_r_clark why do you keep making belittling and insulting comments towards me and the deivce I created and that has inspired many others to follow?

The request Is not about MY device, it is about the class of devices. Re-read my original post.

Its not as simple as you make it out to be.

sinned6915

@phaedrux thanks for replying to the specifics of my query.

I will look into adding them into the wiki.

as far as the config tool goes, I feel that the class of probes should get their own entry. the whats and the hows are what I am trying to start a dialog about.

its a herculean task to try and script and all in one algorithym for all cases- i am not asking for that.
there is no universal solution: it can be a fixed dock or a moving dock, and no 2 printers are ever alike. while there are adaptations to main-line printers, even between those, user preferences and specifics cause customizations.

at a minimum, i would hope that if someone checks an option box for 'detachable probe', that a couple of comment lines could get inserted with some basic instructions or redirect to the wiki.

thanks

sinneD

A Former User

@sinned6915 said in Requesting detachable Z-probe to be added to the config tool:

@arnold_r_clark why do you keep making belittling and insulting comments towards me and the deivce I created and that has inspired many others to follow?

The request Is not about MY device, it is about the class of devices. Re-read my original post.

Its not as simple as you make it out to be.

Sir I am making neither belittling or insulting comments towards you, if you took my observation and comment that I feel the device being advertised is very expensive for what it constitutes of, and the valid question asking why you feel there is a special use case for adding an "extra" category for this "class" of device when it is 100% already catered for then that is a perception that YOU need to deal with instead of trying to blame others.

And having designed and formulated the RRF code for this type of "probe" years ago using spare components I had laying around at nothing more than the cost of my time it is 100% as simple as I make it out to be.

config.g settings are quite normal as the probe type is set to P8 (in RRF-3)

In your homeall.g after X & Y has homed you command the head to a traverse to specific location in a very specific direction/order using the G1 commands to send the head to the probe shoes dock location, you then tell the machine to take the probe shoe out of its dock in a specific manner again using the G1 command, then you allow the Z axis to home itself as normal, after homing (or probing) of the Z axis has completed you command the machine stow the probe shoe back in its dock again using the G1 command there is NO need for any deploy/retract commands whatsoever, as you are technically not deploying or retracting anything you are however collecting and returning the probe shoe to its dock which is all on the same plane.

All very simple commands which take only a few minutes to formulate.

As I can prove what I originally asked as being simpler than you make it out to be, my original question stands. if you take that as being " belittling/insulting" then for that I am sorry that is not how it is intended, I am merely trying to understand the thought process of why you think such a simple class of device to create and to get working in RRF requires a special category when a simple switch is already catered for.

fcwilt

@arnold_r_clark

Well one thing I have discussed with OP is a design change that would allow detecting 3 states (not mounted, mounted but not active, mounted and active) rather than just 2.

To achieve that would require a new type of probe using the analog capabilities of the input to determine the 3 states.

Frederick

A Former User

@fcwilt said in Requesting detachable Z-probe to be added to the config tool:

@arnold_r_clark

Well one thing I have discussed with OP is a design change that would allow detecting 3 states (not mounted, mounted but not active, mounted and active) rather than just 2.

To achieve that would require a new type of probe using the analog capabilities of the input to determine the 3 states.

Frederick

I think the MK1 Eyeball will do most of what you require with no need for any update.

fcwilt

@arnold_r_clark said in Requesting detachable Z-probe to be added to the config tool:

@fcwilt said in Requesting detachable Z-probe to be added to the config tool:

@arnold_r_clark

Well one thing I have discussed with OP is a design change that would allow detecting 3 states (not mounted, mounted but not active, mounted and active) rather than just 2.

To achieve that would require a new type of probe using the analog capabilities of the input to determine the 3 states.

Frederick

I think the MK1 Eyeball will do most of what you require with no need for any update.

Without the 3 states you cannot write bullet proof code to handle all possible situations.

Frederick

sinned6915

@arnold_r_clark again, the point of my post is to add the class of detachable probes to the config tool. have the courtesy to respect the request despite you perosnal bias.

there are literally THOUSANDS of detachable probes out there between the Euclid and its imitators. they are replacing poorly performing BLTouch and inductive probes, and the ranks are growing.

go look at the diffculty that klipper has to make the detachable probes reliable and safe to use. its the wild west on that one becasue of klippers lack of standardization.

sinned6915

@fcwilt as we discussed, it may take some coding to get better detection schemes in place.
it would seem that to make that request more credible, getting it recognized as a viable device first would be a prerequsite.

zapta

This kind of detachable probe is very pupular these day in the voron community and it works very well. I have one on my printer, acting as z stop and z probe.

A Former User

@sinned6915 said in Requesting detachable Z-probe to be added to the config tool:

@arnold_r_clark again, the point of my post is to add the class of detachable probes to the config tool. have the courtesy to respect the request despite you perosnal bias.

I think you should have the courtesy to respect the fact that a simple switch is ALREADY catered for.

It is also very telling from your own words that you feel that anything of the Class (as you put it) of "simple switch related probes" that is not produced by yourself is in your very own words "imitators" did you invent the idea of using a simple switch as a probe ? if so please provide citation of that fact.

the Euclid and its imitators.

The cynical could say that if you were to obtain a "special" category for a simple switch that, that could be used for commercial gain.

install and setup instruction formulated properly would be more than sufficient .

Also no matter how you try to paint it I have no personal bias, I only deal in black and white logical facts, I am not on any side of right or wrong, facts are facts and the fact is 100% that a "simple switch" is already catered for, and to mention klipper is irrelevant chatter as this discussion is about your desire to obtain special status for a system already catered for within RRF-3 NOT Klipper.

A Former User

@fcwilt said in Requesting detachable Z-probe to be added to the config tool:

@arnold_r_clark said in Requesting detachable Z-probe to be added to the config tool:

@fcwilt said in Requesting detachable Z-probe to be added to the config tool:

@arnold_r_clark

Well one thing I have discussed with OP is a design change that would allow detecting 3 states (not mounted, mounted but not active, mounted and active) rather than just 2.

To achieve that would require a new type of probe using the analog capabilities of the input to determine the 3 states.

Frederick

I think the MK1 Eyeball will do most of what you require with no need for any update.

Without the 3 states you cannot write bullet proof code to handle all possible situations.

Frederick

Not exactly so, you can work out two of those three states with NO changes to the (or additional) hardware

lets look at the logic of what you said which was:

not mounted, mounted but not active, mounted and active

Not mounted: RRF-3 can be 100% coded to tell you if the switch shoe is mounted to the head or not
Mounted but not active: Again RRF-3 can be coded to provide that info
Mounted and active: That information is ALREADY displayed by DWC, the DWC status box shows the status of the "probe" be it ZERO or (usually) 1000 and when activated the box around the number changes its numerical value and colour shows up in RED

I would actually propose a Fourth state "Docked" this would allow you to know if the shoe in its dock or not as it might be possible for it to be accidently "dropped" this would be the part that requires extra hardware , I would personally use an optical switch to detect when the shoe enters it's dock, and when in its dock the optical switch reports that fact back to the firmware.

And while I haven't actually looked I am fairly sure conditional g-code could be formulated to only allow the head to go and collect the shoe if the shoe is actually in its dock, that could also be expanded to include a routine that checks if the shoe has been actually been picked up or not .

T3P3Tony

Thanks for all the input on this. We will look at how different types of Z probes are dealt with in general as part of the config tool review which I hope to be aligned with the 3.5 firmware/software release.

I am locking the thread as its starting to get into more of an argument than a healthy discussion.