Figuring out what kind of move is being executed?

cncbasher wrote: have you seen Probe_screen ?

Yes, but I still have to play with it. Currently I am still using something I already had before verser made probe_screen.

i cant see first hand how your idea of using a ball bearing for example will calibrate a probe , as with any probe it can be placed in a toolholder in any position
i can see it working if you can hold the spindle in the same place everytime and it not rotate , and insert the probe in the same axial postion .

That's exactly what I want. Radial position is easily constrained with a simple feeler pin that hits a feature on the head. Axial posiition is less easy since my spindle uses an ER25 nose. But a collet that is ground down so it only touches the cone inside the spindle at three locations op top and three on bottom is reasonably repeatable. Besides that I normally do not require ultra precision on the Z-axis trigger point and if I do I can always touch down on the table.

But I think I am going to move it outside the spindle nose; it is taking up too much of my Z-travel this way. So I will change the mounting to a 3-balls, 3-Vgrooves and a magnet system. I use the same for my USB camera (click) that that repeats to well withing the accuracies of my 0.01mm DTI's.
Would make placing the probe, doing the measurements/zero setting/etc, remove the probe, and go milling a lot easier too.

but i think this is over complicating ...

I don't think so. I made a probe before, but centering the tip to reasonable accuracy is quite frustrating. And keeping that tip centered is another thing.
Besides that all 6-balls-3-rods based probes suffer from lobing because the force required to trip the measurement varies in the circle and things are not infinitely stiff. Which is one of the reasons why I use hardened steel balls/rods and anodised aluminium for the housing and inner parts instead of plastic.

BTW: the electronics does contact resistance measurements and shuts off the current to the contacts as soon as it senses an increase or decrease so that the actual breaking/making occurs without current flow. And thus without micro-erosion of the contacts. If you leave the current on, you basically made an EDM machine chewing away the contacts.
I also intended to fill the contact area with some inert fluid, but so far I have not found anything that works decently. All liquids I tried cause loss of contact problems at very light triggers.
Current contact-area fill is argon, and that works well. But I have no illusions; the argon will diffuse through the NBR70 seals sooner or later.


If the probe calibration is a simple and mostly automatic process and the probe has a fixed orientation compared to the spindle, it is a better solution IMHO. No more tedious centering, lobing is corrected, and it is very easy to construct a probe tip using a hardened steel ball glued onto a piece of carbide rod. Saves money; sooner or later 'oops' happens and the probe tip breaks.
When constructing probe tips this way, the ball is not centered within microns of course. With calibration/correction, that does not matter.

i have a data stream over the ir path , with battery condition and on off states ,

I am using standard IrDA SIR at 115200 baud using a single byte to signal state and extra error correction bits. A fairly slow method to communicate; it gives me a 91 usec latency between trigger detect and output of receiver changing state. But that latency is fixed, and therefore can be corrected when needed. Although synchronized timestamping clocks at both ends would be nicer.

and using Mcodes to start & stop and switch on the probe once it's inserted into the spindle , as mine is used in a toolchanger ,

Aaah, the luxury of a toolchanger

My probe is activated/woken up from standby by triggering the probe itself. Makes sense in my situation, just tap the probe tip once while manually mouting the probe. Happens 'by accident' anyway. And even if LinuxCNC would not react to 'probe ready' the wakeup is fast enough (several 10's of microseconds) to stop the probe before damage occurs.
It goes back to sleep when the communication link with the receiver is broken.
To be really sure I have to deplete a battery first, but calculations show that the CR2032 cell should last several hundred hours of probing (0,6mA average current draw) and many years of standby.(~1uA of current draw).

g38 is used for probe-in at present , but i have not looked at it's limitations

My only issue is that there is only one G38 and only one motion.probe-in. When using more than one probe (toolsetter, touch probe, etc..) one has to OR those signals together, guess which device caused the trigger and if one device breaks the others are instantly not useable anymore without some HAL hacking.
Also the fact that it runs at the servo thread also causes a fairly large uncertainity in the probed position at higher probing speeds. Not so important on my hobby machine, but to be able to use the repeatability of a 'real' probe such as made by Renishaw & co you have to keep the probing speed very low. But I am sure that a bit of Mesa FPGA here and a remap there can solve all that when needed.

When interested (video isn't that interesting really): probe testing using slightly modified smartprobe.ngc from the examples:

DaBit wrote: Also the fact that it runs at the servo thread also causes a fairly large uncertainity in the probed position at higher probing speeds. Not so important on my hobby machine, but to be able to use the repeatability of a 'real' probe such as made by Renishaw & co you have to keep the probing speed very low.

One solution is to make a fast probe move until the probe breaks contact, then make a slow probe move in the reverse direction until the probe makes contact.

Time-stamping the probe event might not help much. You find out when the event happened but you really care about where it happened, and the encoder counts only get converted to position in the servo thread

There is _something_ mysterious and undocumented in the Mesa encoder related to latched counts, it might be possible to use that.

Docs: www.linuxcnc.org/docs/html/man/man9/hostmot2.9.html#encoder
Actual pins created in code: git.linuxcnc.org/gitweb?p=linuxcnc.git;a...563943d;hb=HEAD#l461
And a mention of "LATCH_ON_PROBE" git.linuxcnc.org/gitweb?p=linuxcnc.git;a...563943d;hb=HEAD#l775

I _think_ this suggests that you would connect the probe to the index pin on the interface board.

andypugh wrote: One solution is to make a fast probe move until the probe breaks contact, then make a slow probe move in the reverse direction until the probe makes contact.

That's how I do the toolsetter at the moment. 'crash' the tool onto it, move back slowly.

Time-stamping the probe event might not help much. You find out when the event happened but you really care about where it happened, and the encoder counts only get converted to position in the servo thread

If we have a synchronised clock running at both the probe and the control, timestamping helps. Control 'knows' the position at t=0, t=1, t=2, etc. The probe knows that an event happened at t=1,27 so it can send an 'event, probe trigger, t=1.27' message to the control. It sends it to the control by snail mail, so let's say it arrives at t=12. But when it arrives, the control knows it happened at t=1.27, and can do an interpolation of the known positions and velocities at t=1 and t=2 (or more) to calculate the position at t=1.27

There is _something_ mysterious and undocumented in the Mesa encoder related to latched counts, it might be possible to use that.

Yes, it could be done by feeding an encoder a fake encoder signal to keep the counter running and then latching it. I never got latching to work though (probably my idea of what was supposed to happen was not correct), but using the index pulse and some arithmetic with rawcounts/counts should be possible somehow.

However, that is a lot of effort for relatively little benefit since the processing (inside the probe) and communication latency is still there. With the timestamping clock it is possible to capture the event in hardware at the probe; every modern microcontroller supports input capture including the STM32L051 I used in the probe. That's good for submicrosecond resolution if desired and hardly takes programming effort.

If I ever want to go the timestamping route, it would be nicer to implement the IrDA communication itself in the FPGA, which is no more than a simple UART with a 3/16 modulator/demodulator attached. That would make the receiver interface for the probe extremely simple (only the physical IrDA transceiver). Clock synchronisation would be fairly easy too; clock frequencies are known, clock ticks required per operation is known, latency of the comm channel is fixed, and it all happens at the same moment in time as latching the encoder counts etc. because it is triggered by the same hm2_5i25.0.read function.

Oh well, for now I just chicken out and use motion.probe-input with the receiver board digital outputs attached to the 5i25 :laugh:

i use paraffin or whats known as lamp oil , for filling electrical areas , it's also good for keeping water out , under extreme pressure , such as vent monitors at the bottom of the ocean floor , as an example
you should find nitrogen , or argon a good second if you can seal and make it leak proof would be more of a challenge .

I tried lamp oil, fuel oil, various flavours of low viscosity hydraulic oil, silicone oil and naptha. All of them have problems when the probe is triggered and then slowly released. Works well for 1000 trigger actions, but number 1001 and it takes seconds to make contact again. It is not that there is no contact at all; contact resistance keeps on hovering in the 100-200Ohm range.
Increasing contact pressure does not solve this. I also tried increasing contact measuring current from 15mA max to 80mA max (it doesn't reach that when resistance is 100+ ohms with only 3V supply), no success. Once I use the lab supply set at a higher voltage contact resistance instantly drops to a normal 1-2 Ohms.

Thus, somehow a few liquid molecules stay between the contact patches of ball/rod. If I use a higher voltage I manage to burn the contacts free of that, but that's playing EDM machine...

Argon does not suffer from this. Works perfectly, just as well as air. I only wonder how long it would take for the argon to diffuse through the nitro-butyl rubber bellow (and PCB, but that one is 98% copper on the bottom) that seals the contact chamber. Or a better question: how long would it take before moisture and oxygen levels inside the chamber are high enough to cause corrosion of the hardened steel contacts...

have you tried gold plating the balls etc , although removing the chrome may be the worst point ,

how much current and voltage are you dealing with across the contacts ? i.e on a contact break & on contact make


( sent you pm )

i think we can solve this .