Oh well, those are 400 dollars down the drain. I still can't believe I got ripped like that.

I can't buy a new motion control board right now, so, for the time being, I am using the method I described before, a macro that issues a stop command when the Digitizer LED is on, and then writing to a file the corresponding data.

It is a very tedious process, almost manual, since after every stop I have to press Star Cycle twice to keep going with file execution, and that may happen for 100 to 200 points on a given surface, it is quite reliable, but repeatability tends to drift every so often. Unfortunately that is the only way I can do things right now without replacing my Motion Control board.

 

you can use your own scripts to create the file.

for example create a file M400.m1s in your macro folder to get the filename, M401 is called only at the
beginning of your G-Code.

code for M400.m1s:
'M400 for digtizing
'get the filename for digfile from user

Sub Main()
 If NOT Isloading() then
Dim  FNum, FName ' Declare variables.
'get Filename from user

Begin Dialog TextBoxSample 16,30,180,96,"enter digfilename"
OKButton 132,20,40,14
Text 8,8,132,8,"filename without extension:"
TextBox 8,20,100,12,.TextBox1
Text 8,44,132,8,"file will be in c:\Mach3\GCode"
End Dialog
Dim Dlg1 As TextBoxSample


Dialog Dlg1
SetUserLabel(255, Dlg1.TextBox1)

'open the to file errase all existing data
FNum = FreeFile ' Determine next file number.
FName = "C:\Mach3\GCode\" + GetUserLabel(255) + ".nc"
Open FName For Output As FNum ' Open file.
Close ' Close all files.
SetUserDro(1166,1)
   End If
End Sub

now create a file M401.m1s in your macro folder witch is called afte each G31 to save the values.

code for M401.m1s
'M401 for digtizing
'write the values into digfile

Sub Main()
Dim  FNum, FName ' Declare variables.

'wait for axis standstill
WaitForMove

'open the file for output data data
FNum = FreeFile ' Determine next file number.
FName = "C:\Mach3\GCode\" + GetUserLabel(255) + ".nc"
Open FName For Append As FNum ' Open file.
Print #FNum, nFmt(GetDro(0),4) & "," & nFmt(GetDro(1),4) & "," & nFmt(GetDro(2),4) 
Close ' Close all files.

End Sub

'global Sub's
Sub WaitForMove ()
While IsMoving()
Sleep(5)
Wend
End Sub

code is not tested, just written down

That is almost exactly what I am doing, except that I am not using the G31 command for the probing. As stated before, G31 is also poorly supported on this WiXHC board; when probing, the probe goes from 0.2 - 0.5mm lower before reading the data and sending it to the file, that is why I opted to do what I mentioned:

I am using the method I described before, a macro that issues a stop command when the Digitizer LED is on, and then writing to a file the corresponding data.

It is a very tedious process, almost manual, since after every stop I have to press Star Cycle twice to keep going with file execution, and that may happen for 100 to 200 points on a given surface, it is quite reliable, but repeatability tends to drift every so often. Unfortunately that is the only way I can do things right now without replacing my Motion Control board.

Since there is no Gcode to stop axis movement, I have to do it this way.

It makes me wonder now how the G31 command works internally. It has to tell the controller to "stop" right when the probe is tripped, but how without stopping code exection?

Someone mentioned that G31 does some kind of very rapid deceleration when probe is tripped, but it still has to come down to a stop. Anyway, maybe it comes down to some really fine and proper code, and once again, like I said before, I may have to write my own G31 command at some point somehow, right now I am just too mad at how I got ripped.

 

Hi,
this is from the Mach4 API document file. There is no equivalent document for Mach3 but the procedure is almost identical.

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

I think the way that G31 must work internally (depending on the controller) is as follows.
- The axis is moved at the commanded speed by issuing a pulse train, and at each pulse a register R is incremented which indicates the amount of movement;

- At the same time the axis DRO is incremented and shows the actual current tool position;

- When the probe triggers the value of R is read and the deceleration started at the programmed rate;

- The value of R and the start position are used to derive the axis point at which the probe triggered - note that this is NOT the same as the final position the axis stopped at because of the inevitable over-travel.

Obviously this has to happen in a "real-time" environment, i.e. in the motion controller.  I wonder if the problem with your controller is that it erroneously reads the final axis DRO position and doesn't have the "R" function?

Since there will always be some overtravel as the deceleration has to be controlled to avoid losing steps, ideally the probe needs to have some over-travel capability.  This is built into all "professional" probes such as Renishaws (who effectively invented the CNC probe).  To set tool height I have a setter with a spring-loaded contact button allowing at least 0.5mm of over travel.  I use a simple contact for X and Y as it's harder to arrange for the over-travel, but I can see that some error is likely - but I use a very low probing speed.

Another odd point is that the latest Renishaw wireless probes have an inevitable delay between contact and asserting a logic level.  They work in a very noisy environment EMC-wise and use standard ISM bands (2.4 GHz?) that also carries Wi-Fi and Bluetooth and industrial heating and microwave ovens etc.  So they need to use a special protocol to ensure error-free transmission which inserts a delay, and this is engineered to make the delay a very precise 5ms (according to a presentation I recently heard from a Renishaw engineer).  Clearly the machine controller needs to know what the delay is to back-compute the actual probe trigger point once it gets the signal.  Neither Mach 3 nor as far as I know Mach 4 have a parameter to set the delay.  The delay also adds to the required over-travel.

NB: I posted this before seeing Craig's post, I hope what I said broadly corresponds though I can't say I understand the document at all!

Hi,

This post I deleted because I used the wrong value fpr acceleration, see following post.
Craig

Hi,

- The value of R and the start position are used to derive the axis point at which the probe triggered - note that this is NOT the same as the final position the axis stopped at because of the inevitable over-travel.

This is incorrect. The motion controller decelerates the axis until it stops. When it is stopped that is the value that is latched into the register. So there IS overtravel
in EVERY probe command. For this reason you want the probe to happen at low speed and have the machine decelerate as fast as possible so that the overtravel is
minimized, but you can't eliminate it.

To give you an example:
My current mill has an acceleration of 1.5m/s². I regularly probe at a feed rate of 100mm/min or 0.0017m/s. The overtravel is:

OT= 1/2 x a x t²  where a is the acceleration and t is the time taken to stop. The time to stop is:
t_stop=v_initial/a
=0.0017/1.5
=0.00067 seconds
OT= 1/2 x 1.5 x 0.00067²
=0.33um

So I expect my machine to overtravel less than 1um when probing from 100mm/min.

If you read closely the excerpt from the Mach4 documentation I posted you will see that the position is latched only when the axis is stopped, and Mach3
behaves exactly the same way and always has.

Craig

Thanks Craig, I stand corrected.  But it seems a crazy way to do it when it would be simple to just copy the value of the DRO, or something corresponding to it, when the probe triggers.  Yes, you still have to decelerate but the overtravel is irrelevant to the measurement.

My point about delay stands.  In your case, if you were using a Renishaw probe with a delay of 5ms, the overtravel would increase to 24 microns.  If the controller knew the delay it would be trivial to compute the overtravel due to this and deceleration and correct the probed value, but certainly in Mach3 and possibly in M4 there isn't a probe delay parameter as far as I know.

Edit a few minutes later:  UCCNC operates in just the way I described - the probe trigger interrupts the processor, stores the value at the interrupt point, then decelerates.  Not clear if they have a delay parameter.

Hi,

But it seems a crazy way to do it when it would be simple to just copy the value of the DRO,

Yes, you might think so but trying to latch an 32 bit integer during one clock cycle??? Seems that no-one does so, but rather latch the number
when the axis has stopped. All of the motion controller manufacturers do it that way, including Machs parallel port.

if you were using a Renishaw probe with a delay of 5ms,

So where does this 5ms delay come from....thats BS, you could not possibly achieve anything like accurate probing with that sort of delay.
I would anticipate that the motion controller can start to decelerate the axis within ten microseconds, and the deceleration phase should not last more than
a few hundred microseconds. Total delay from probe trigger to stop less than 500 microseconds, and the value latched into the motion controller register
a few hundred microseconds after that. There may well be a delay of tens of milliseconds before the integer value is reported to Mach, but the delay
in the trigger-decell-latch phase should be well under one millisecond.

Craig