Investigating various touch-trigger probe types, I've noticed that their developers often gather statistical information on performance.  For example, if the probe touches off on the same surface 100 times, what is the mean and standard deviation of the resulting measurement?  This should be a fairly easy thing to automate with a Mach 3 macro, but before I do so I was wondering if anyone has been here before me and could share the code please?

John.

think a easy way would be to write machine coord's int a file (directly after probing code) like:


Open "C:\Mach3\probecoords.txt" For Append As #1 ' Open to write file.

'write machine coord's
Write #1,"X: " & GetOEMDro(83) & " Y: " & GetOEMDro(84) & " Z: " & GetOEMDro(85)

Close #1





Hi,
I use probing to measure the Z height of PCB blank material which is then used in a software levelling program. Each circuit board
may have up to a hundred or so sampling points stored in a probe data file.

I always review the raw data before I commit my Gcode to the levelling program so I see the raw results, and as I use this program for
work, I see it at least daily, more often several times a day. I have never bothered to do any statistical analysis of the results but I expect, in fact demand,
that the probing accuracy be at least as good as 0.01mm or 10um. In practice I achieve better than 5um repeatable accuracy.

I used this same procedure with Mach3 some six plus years ago with the same result as Mach4 which I have now used for six years.

In short probing has proved to be very accurate.

One determinant of good and repeatable probe data is machine acceleration.

A G31 probing command, for example G31 Z-5 F100, will cause the Z axis to descend at 100mm/min until either it detects a probe strike OR it reaches -5mm
WITHOUT encountering a probe strike. We will assume that the probe does in fact touch the workpiece, the electrics of the probe are good and therefore Mach detects
the probe event. Mach will decelerate the Z axis at max tuned acceleration until stopped and then record the Z axis position as the probe data.

If the machine has very slow acceleration then the probe will strike but the machine will continue descending in Z until it stops, called probe overrun. The slower the
machines acceleration the greater the overrun. Unless you have a very slow machine OR you attempt to probe REALLY fast it is seldom an issue.

For example my machine is tuned for accelerations of 375mm/s², respectable but not blinding fast. I have settled on a probing approach speed of 100mm/min
as a good balance of time taken and accuracy. With that acceleration and probing speed the probe overrun is 3.6um....which is highly acceptable accuracy to me.

Craig

Thanks Craig, that's useful.  My motivation is only partly to characterise a probe, I also want to investigate the sensing accuracy of an opto interrupter for use on pendulum clocks.  I'm thinking that using my CNC mill to do slow traverse of the opto past a thin vane or rod in the chuck, and using the opto to drive the probe input, should provide an accurate and automatic way to do this.  I will be using a very slow G31 feed - in fact I tend to play it very safe using F5 usually for probing, manually positioning the probe close to the surface first.  Could you possibly share the Mach 3 macro please?

John.

Hi,
I don't use Mach3, and haven't done for years, I use Mach4 instead.

The software utility Autoleveller is what generates the Gcode for the probing net, but the code itself is nothing too
difficult, just  series of G31's with a G0 move to the next probe point in between.

Craig

I think you have the explanation wrong. In mach3 after the probe trips it first records the position THEN slows to a stop. But the variable is always the feedspeed. And that is not saying any speed is more or less accurate it is just a different value. That is why you should pick a speed and then set your calibration to that speed. also the axis acceleration comes into play. Not in the way you think. IF the accel is too slow or the distance from the start and trip is too small the axis will not be up to the programed speed for probing. Also note that these varibles are extremely small (;-) most time not worth mentioning.

Just a thought, (;-) TP

Thanks TP - your description is how I thought it worked.  For this experiment I will use a slow probing speed and make sure the approach is from a reasonable distance.

Hi,
that is incorrect, Mach cannot capture a moving DRO, it has to stop before it can read it.

This is from the Mach4 API, and Mach3 performs nearly indentically:

Probing
Motion plugin probing procedure.
The probe moves are really just G01 moves in exeact stop mode with the addition of being marked as EX_PROBE in the execution_t struct from mcMotionCyclePlannerEx().

When executing a G31, the core considers the move as an exact stop move and therefore will request a motor stop report. It waits on one of two conditions:

A probe strike condition where the motion plugin calls mcMotionSetProbeComplete().
An end of move condition where the motion plugin reports the motors as being still.
Until either of these conditions are satisfied, the core will generate no more moves after the EX_PROBE marked moves. In other words, all you will get out of mcMotionCyclePlannerEx() will be EX_NONE type data. In the event of a probe strike, this makes it safe to clear the planner and be sure that future moves are not removed by accident.

A motion plugin should implement probing in the following way:

Upon seeing the first move marked as EX_PROBE, the plugin should arm position latches on the hardware.
Then consume the EX_PROBE marked moves as normal.
If the probe stikes, the plugin should:
Cancel any motor stop report requests (retrieved from then execution_t::move_t::exMotors structure). (see below. VERY important!)
Report the latched positions via mcMotionSetProbePos() for each motor.
Clear the hardware of any additional moves.
Call mcMotionClearPlanner() to clear the Mach planner of any unretrieved EX_PROBE moves.
Update Mach with the hardware's current position via mcMotionSetPos().
Call mcMotionSetProbeComplete().
If any motor stop report requests has been received, do not acknowledge them. mcMotionSetProbeComplete() does this for you and a position sync as well.
If no probe strike, then the move continues to it's end point as if it is a regular move.
The plugin should ack any motor stop report requests with mcMotionSetStill().
The positions latches should be disarmed (if needed) when a MSG_PROBE_DONE is seen.
In the event that the probe move is aborted, the plugin should:
Call mcMotionClearPlanner() to clear the Mach planner of any unretrieved EX_PROBE moves.
Call mcMotorSetPos() for each controlled motor.
Call mcMotionSync.
Call mcMotionSetStill() for each controlled motor.
Probe Operation Overview.
Upon executing G31, the core will mark those moves as EX_PROBE in the data stream.
If the probe strikes before the end of the G31 move, the plugin aborts the rest of the probe moves as described above. If a probe data file has been opened via mcCntlProbeFileOpen(), then the positions recorded by the motion plugin are inserted into the probe data file in the specified format.
If the probe doesn't strike and the G31 move reaches its end point and a probe data file has been opened via mcCntlProbeFileOpen(), then the end point positions are inserted into the probe data file in the specified format.
Using the probe data file routines.
int mcCntlProbeFileOpen(MINSTANCE inst, const char *filename, const char *format);
The format argument is a printf style format with expanding macros for the axis values. AXIS_X, AXIS_Y, AXIS_Z, AXIS_A, AXIS_B, AXIS_C. It is used in the following manner:


mcCntlProbeFileOpen(inst, "myProbeFile.csv", "%.4AXIS_X, %.4AXIS_Y, %.4AXIS_Z");
This will produce a probe file in CSV format like so:



1.0000, 2.0000, -1.4356
1.0100, 2.0000, -1.4343
1.0200, 2.0000, -1.4324
...

A format of "X%.4AXIS_X, Y%.4AXIS_Y, Z%.4AXIS_Z" would yield:



X1.0000, Y2.0000, Z-1.4356
X1.0100, Y2.0000, Z-1.4343
X1.0200, Y2.0000, Z-1.4324
...

A format of "X%.4AXIS_X\tY%.4AXIS_Y\tZ%.4AXIS_Z" would yield a tab delimited file:



X1.0000 Y2.0000 Z-1.4356
X1.0100 Y2.0000 Z-1.4343
X1.0200 Y2.0000 Z-1.4324
...

int mcCntlProbeFileClose(MINSTANCE inst); Closes the probe data file

Craig

Right!  Thanks for the explanation.  So there could be a small error because of the time taken to decelerate to a stop but this should be constant for a given probing speed?  And if the speed is low and deceleration profile not too flabby it should be small as well.

And once the probe move is complete, Mach 3 should have the probed position in the appropriate DRO?

Well according to ART long ago when we were testing the G31 for just what you are testing now it records then stops. The speed does not affect accuracy it just causes a different value . I remember spending a solid week trying to prove Art wrong but did not. I remember that because Mach3 crashed a VERY expensive highly accurate probe that week.  It was an $1800 repair to fix it. The price for playing on the bleeding edge at that time.

Just a thought, (;-) TP