Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: alvaroevc5 on June 13, 2022, 10:43:39 PM
-
Hello Mach 3 People!
Recently, I was trying to use the probing feature on Mach3 to do surface leveling, but something strange is happening and I don't know if it is because of something in Mach3 or because of my WiHXC Ethernet motion control card.
The description of the whole thing goes like this:
- Before I start probing, I open a file with G40 command -> THIS IS OK.
- When I start probing, everything goes fine, the CNC mill goes to every single point and does its thing with the probe, and the digitizer indicator lights up accordingly as well.
- The DROs move as they should.
- I close the file with G41 command.
- And... when looking at the file, all the points recorded are the same, the X variable across its column has the same number, and the same thing happens with the Y and Z variiables recorded. -> THIS IS THE ISSUE.
After going all over to see where those numbers came from, I saw that what is being recorder are the Work Offsets for every single probed point, which is strange, since G31 is supposed to get the data from the #2000-#2005 variables. The work offsets have to exist, I mean, you are not always going to place your stock at (x0,y0,z0).
So... why could this be happening?
Is it a simple thing due to configurations, or is it due to my motion control card?
-
Please post your code.
-
Please post your code.
Lil' detail I forgot.
Just to mention, I already tried to add 2002 macro (didn't work), somewhere in the Mch3 forum someone mentioned adding a G49 before G31 to cancel tool length compensation (didn't work, and I don't think it had to do with the problem, but during desperate times, you try anything), I also added #500=#2002 before each G31 (didn't work).
Here is the Gcode file:
-
Um, as I read your code (and use a search box in edit), I don't see ANY G31 commands? You need something like this after each XY move:
G31 Z-5 F50
while ismoving wend (waits until the move has stopped)
(then commands to move up to just clear, followed by a repeat G31/while/wend at a slow rate)
Then you read the probed height from the #2002 variable and write it to where you want it
Then lift the probe clear and move to the next XY point.
-
Um, as I read your code (and use a search box in edit), I don't see ANY G31 commands?
Sorry, I uploaded the wrong file. After fiddling so many times with the code I have too many variants of what I have done.
(then commands to move up to just clear, followed by a repeat G31/while/wend at a slow rate)
Then you read the probed height from the #2002 variable and write it to where you want it
Then lift the probe clear and move to the next XY point.
So it has to be done with a while loop? I read in the official Mach3 documentation that:
"After successful probing, parameters 2000 to 2005 will be set to the coordinates of the location of the
controlled point at the time the probe tripped and a triplet giving X, Y and Z at the trip will be written to
the triplet file if it has been opened by the M40 macro/OpenDigFile() function (q.v.)"
So reading the variables and manually writing to the file is not necessary, it's all supposed to be done by the G31 command.
This is the actual file used:
-
The statement
While IsMoving()
Wend
just halts the macro execution while the G31 move is happening. Once the move is finished and the coords are written to the parameter registers execution can continue. All the probe routines that I have seen use this construct. Maybe you aren't giving the system time to finish probing? Also see this thread:
https://www.machsupport.com/forum/index.php?topic=25414.0
-
While IsMoving()
Wend
I will try this and see how it goes.
I'll implement it and grind the idea of how exactly that works. I do know how to code, but this Mach3 language and it's functions are new to me. Time to get into it!
-
I already did:
G31 Z-5 F50
while IsMoving()
wend
No luck, I still get the Work Offset values....
This is stressing me quite bit... >:(
Why something so simple has to be so complicated? :-\
-
Doh! Sorry I've been a bit thick here. All the probing routines I have used have been MACROS, not .nc files. That is, they are written in Cypress Basic (CB) (equivalent of Visual Basic). The "while ismoving() / wend" construct is a CB command. A probing macro would then include a phrase such as:
Code "G90 G31 Z #1 F" & ProbeFeed1 'Fast probing move
While IsMoving () 'Wait until task has been completed
Wend
Notice that the Code command causes the CB interpreter to issue a G code command to Mach. In this case it's a G31 in absolute mode (G90) to a level set in variable #1 and at a rate determined by ProbeFeed1. This comes from a tool height macro which is below. I guess you are trying to do auto levelling of some sort? I notice that your code has a lot of XY moves written in-line, if you write it as a macro you can use a couple of for-next loops (or whatever CB calls them) which makes everything much easier. There are also autolevelling macros around - see for example https://www.autoleveller.co.uk/.
'Tool Height Setting Macro - JLH v1.1 - 4 March 2013
'This version has a 2-phase approach, fast for speed & slow for precision.
CurrentAbsInc = GetOemLED (48) 'Copy current G90/G91 state
CurrentGMode = GetOemDRO (819) 'Copy current G0/G1 state
CurrentFeed = GetOemDRO (818) 'Copy current feedrate
Contact = 0 'Clear the contact flag
PlateThickness = 38.84 'Touch Plate thickness is set here
ProbeFeed1 = 50 'Fast probing feedrate is set here
ProbeFeed2 = 5 'Slow probing feedrate is set here
SetVar (1, -5) 'Maximum probing distance is set here
SetVar (2, 50) 'Retract height is set here
Code "M5" 'Ensures spindle is not running
Code "G21" 'Ensure metric units are used
Zs = GetOemDRO (61) 'Copy current Z-Scale DRO
Call SetOemDRO (61,1) 'Set Z-Scale DRO to 1
DoOemButton (1010) 'Zero Z-Axis DRO
Code "(Setting Tool Zero)" 'Message for status bar
While IsMoving () 'Wait until task has been completed
Wend
If GetOemLED (825) = 0 Then 'Check to see if touch plate is not already grounded
Code "G90 G31 Z #1 F" & ProbeFeed1 'Fast probing move
While IsMoving () 'Wait until task has been completed
Wend
If GetOemLED (825) = True Then 'Check to see if probe has touched plate
Contact = 1 'Set the contact flag
End If
DoOemButton (1003) 'Clear a possible feed-hold condition
ProbePos = GetVar (2002) 'Exact point probe touched
ProbePos = ProbePos + 1 'Displace probe position upwards by 1mm
Code "G0 Z" & ProbePos 'Lifts probe 1 above fast feed endpoint
While IsMoving () 'Wait until task has been completed
Wend
Code "G90 G31 Z #1 F" & ProbeFeed2 'Slow probing move
While IsMoving () 'Wait until task has been completed
Wend
If GetOemLED (825) = True Then 'Check to see if probe has touched plate
Contact = 1 'Set the contact flag
End If
ProbePos = GetVar (2002) 'Exact point probe touched
Code "G0 Z" & ProbePos 'Lifts probe to exact touch position
While IsMoving () 'Wait until task has been completed
Wend
Call SetDRO (2,PlateThickness) 'Set Z-Axis DRO to Touch Plate thickness
Code "G0 Z #2" 'Retract off Touch Plate to the set height
While IsMoving () 'Wait until task has been completed
Wend
Code "(Z-Axis is now Referenced.)" 'Message for status bar
Code "F" & CurrentFeed 'Restore feedrate to original setting
If Contact = 0 Then 'Probe reached max travel without touching
Code "(ERROR - Probe did not touch.)" 'Message for status bar
Response = MsgBox ("ERROR - Probe did not touch.",37,"Auto Tool Zero")
End If
Else
Code "(ERROR - Touch Plate is grounded.)" 'Message for status bar
Response = MsgBox ("ERROR - Touch Plate is grounded - Check connection.",16,"Auto Tool Zero")
End If
Call SetOemDRO (61,Zs) 'Restore Z-Scale DRO to original setting
If CurrentAbsInc = 0 Then 'If G91 was in effect before then return to it
Code "G91"
End If
If CurrentGMode = 0 Then 'If G0 was in effect before then return to it
Code "G0"
End If
-
That is right, I have been trying to do autolevelling, and the software I am using to do it is precisely Autoleveller.
The file I posted is the PFG probing file for a certain area, so that is the code produced after using the software.
I will test what you posted JohnHaine and see how it goes, this subject is killing me quite a bit to be honest. Out of all the complex features that work, the simplest one is the one giving me a lot of trouble.
Another question arise though. Let's say the probing macro works in my case, but, how could I write the XYZ coordinates to a file?
I thought M40 would only get written to by the G31 command. Does this mean that M40 gets written to after the probe has tripped, regardless of the G31 command being used or not?
-
I would have thought M40 is quite independent. After a probe move the trip coords are just held in the specified parameter registers and it's up to the following code to read them and store in a file. But I have never used it so can't confirm. If you are having Autoleveller problems I suggest you raise them with the originator.
-
I can confirm it is not an Autoleveller issue, all that software does is write Gcode depending on some other file. The interpretation and execution of the codes are all inside Mach3.
It doesn't matter how slow I go or how many other complementary pieces of code I add, the Work Offsets still get saved in the file after the G31 command insted of the Work Coordinates, seems more like an issue on how the G31 command is coded, but that is something not visible to the user, all the user can see and modify are the M codes.
I began reading about Cypress code, which is the language Mach3 is based on when writting your own macros. I'll end up making my own G31 command, which is ridiculous, but I have no other choice. Rants about it might go later on.
-
I suggest that you try a very simple single Z probing move at one XY point, after first opening a data file, then close it, then look to see what is written. I know that probing itself works, though I haven't tried writing to a file. Searching on Autoleveller there seem to be several threads on problems with it and solutions.
Writing a G31 command is not going to be easy - what you don't see is that behind the scenes there is a very tight loop to stop the axis moving very quickly when the probe trips. You would have to use a G1 command to move the probe and find a way to stop the move in response to a hardware input before it completes, or move it in very tiny increments, testing the probe state after each one. Anything you write in CB will be rather slow anyway.
-
Right, so I have done a couple of experiments on my mill using the tool height setter and a square-ended rod in the chuck as a probe. The setter is basically a spring-loaded button at a known height of 38.84mm, which is grounded via the rod on contact. I used my tool height setting macro initially, then also a straight G31 move. Both of these verified that G31 operates and writes the XYZ PROGRAM coordinates to a specified file. In the case of my macro two readings are written, for the fast and slow probe moves, they are very slightly different on Z but of course X and Y are the same.
So I suggest you try the following.
a) Type M40 into the MDI text box and return - when a file dialogue appears type a suitable filename.txt into the appropriate box and save it somewhere you can find it quickly.
b) Position the probe just above (say 1mm) the surface to be probed and take a note of the displayed X and Y coords (and Z if you like). Suppose the Z value is Z0.
c) Type G31 (Z0 - 2) F5 into the MDI box and press return. The probe should start moving slowly down until it contacts the surface then stop.
d) Type M41 into the text box to close the file you just created and wrote to.
e) Now from Windows navigate to where you saved the file and open it - it should have one line with the X, Y, and Z coords in it corresponding to the values shown on the system DROs.
I had no problems whatever getting this to work and I conclude that probing is working as documented. It is conceivable that whilst your Ethernet controller does support probing, for some reason it doesn't support the protocol to write the values into the file. Probing motion is a function of the controller since very tight coupling is needed between the motion control and sensing the probe trigger, how the coord values get written to the file is a Mach3 function. I have a Win10 Dell mini Inspiron PC with USB connection to a UC100 motion controller.
-
The other thing to try is to make sure that the G31 is correctly populating the #2********* variables, this might need you to write a simple macro.
-
Sorry to say, but, none of the suggestions above worked. :(
I gave up on tweking the G31 command with other macros, I have spent too much time trying to figure out what's under the good to make it work.
Instead of reverse engineering or trying to patch the command, I just began writing my own probing macro from scratch, and so far, it has given me waaaaaaaay better results, with a few caveats that I wish could be solved as nicely as what I have done so far.
To summarize what I did with the G31 in the end, was just to use it as code to stop the machine from moving when the probe tripped. Unfortunately, after repeated tests, I found out that no matter how slow I did de probing, the machine would go about 0.3mm lower from the contact point. From what I tested, it seems that it has to do with how the G31 command is coded, it is either too slow or doesn't properly tell the machine to stop right when the Digitize LED is ON. It just keeps going lower after the probe has tripped.
Right now, I created a macro to issue a Stop command (1003) when the Digitize LED goes ON, and it works amazingly well. The problem now with this stop command is that, I have to manually press Start Cycle in order to get the file running again, and by pressing Start Cycle for some reason it goes one line before it stopped, which is causing a double reading on my file, which is surprisingly quite accurate, but not what it's intended.
So my question now is, is there a Gcode to stop movement without stopping file execution?
I tried, G1 F0, but it is not allowed, Pause Feed Hold (1001), and JogOff(Zaxis), but since it is not actually JOGGING it didn't do anything, I just did it to try it out.
-
Hi,
To summarize what I did with the G31 in the end, was just to use it as code to stop the machine from moving when the probe tripped. Unfortunately, after repeated tests, I found out that no matter how slow I did de probing, the machine would go about 0.3mm lower from the contact point. From what I tested, it seems that it has to do with how the G31 command is coded, it is either too slow or doesn't properly tell the machine to stop right when the Digitize LED is ON. It just keeps going lower after the probe has tripped.
When the probe is tripped the machine decelerates to a stop, so yes there is overtravel, but 0.3mm???? No way, even my old stepper driven mill which had acceleration of 375mm/ss stopped with 4um after probe trip when decelerating
from 100mm/min. My new mill has acceleration of 1500mm/s2, ie 0.15g , and that's detuned from its rated 0.27g rated deceleration, so the over run is 1-2um. If you have overtravel of 0.3mm your machine has too
low acceleration to probe, fullstop.
Craig
-
"So my question now is, is there a Gcode to stop movement without stopping file execution?"
Probably not. The only way to do what you want is to use a macro to move in very small steps, testing a hardware input at each point. Veeeryyyy slow. As Craig says, it seems amazing that you're the first person to have discovered this, like him I suspect the machine setup.
-
No way, even my old stepper driven mill which had acceleration of 375mm/ss stopped with 4um after probe trip when decelerating
from 100mm/min. My new mill has acceleration of 1500mm/s2, ie 0.15g , and that's detuned from its rated 0.27g rated deceleration, so the over run is 1-2um. If you have overtravel of 0.3mm your machine has too
low acceleration to probe, fullstop.
Thanks for the reply and the insight on that matter. Well, I actually overhauled my CNC mill a few months ago with closed loop stepper motors (Nema 23, 3.0Nm, 4.0A) enough and their respective stepper drivers because the steppers it had before weren't bulky. I also added a WiXHC MK6 Ethernet controller, all because the cheap chinese CNC USB motion controller I had before had me replacing broken tips because of noise in the data lines.
I also just checked my acceleration settings for each motor, and they are all at 400mm/s2, which should in theory give me the same results. If not, what acceleration settings would be recommended for the sake of testing?
The only way to do what you want is to use a macro to move in very small steps, testing a hardware input at each point. Veeeryyyy slow. As Craig says, it seems amazing that you're the first person to have discovered this, like him I suspect the machine setup.
I already player with macros and going very slow, but I still get significant overtravel, not to mention once again that the G31 command within the G40 which opens a file just gives me some other data instead of the one being probed like I mentioned at the beginning of the thread. If I am the only one experiencing this, then I am just too unlucky.
:(
-
I suspect that your motion controller doesn't properly support probing.
-
I suspect that your motion controller doesn't properly support probing.
It does, or at least that's what the engineers that develop the controller say. I contacted customer support and their engineers and they mentioned that the G31 command does what it is supposed to do. I have seen in other web pages and forums that people use this type controller, but there aren't many others posting details about it.
-
Hi,
you're lucky to get a response from XHC at all. I don't think any of the development engineers are left. The company just makes copies of what they have made before
without any detailed insight into how they work, or in this case, don't.
Craig
-
Hi,
I use Autoleveller, a software utility that probes the surface of a nominally flat printed circuit board blank. Then it manipulates the Gcode file to accommodate the inevitable wave and/or warp
of the blank. As such probing has to work well and accurately, say within a few um otherwise it does not work.
Initially I used Mach3 and a parallel port, and Autoleveller worked well, ie within a few um.
Then I used Mach3 and an Ethernet SmoothStepper, and that worked well also.
Then I went to Mach4 and the ESS and have used it extensively for seven years. With my new build mill, having quite good acceleration, I can get about 1.5um accuracy/repeatability with g31 moves.
I use it daily, if not multiple times per day, so g31 works. It's something about your machine, or as John has postulated, the controller. Consider getting a US or European made controller, we know they work
and the manufacturers support them, unlike the Chinese manufacturers.
Craig
-
Well, those are sad news, I spent about 400 dollars on that controller thinking it was something fairly good, you know, better than the controller kits that come with cheap CNCs. I bought that one also because I read in quite a few threads that Mach4 is still quite unstable, and this WiXHC is compatible with Mach3 which has been going around for quite a while.
Hi,
you're lucky to get a response from XHC at all. I don't think any of the development engineers are left. The company just makes copies of what they have made before
without any detailed insight into how they work, or in this case, don't.
Craig
What do you mean by "I don't think any of the development engineers are left"? The company isn't up and running anymore. For what I have seen they are still active and bringing new products out there....
What are the good reliable brands then? Any recommendations? Not that I would buy it any time soon, because you know, money. I feel cheated :(
-
Hi,
the only person who responds to any enquiry about XHC products is a guy Alex Hee, and he only replies sometimes. Further he does not answer any detailed technical questions
and I would guess he can't. Have a close look at the 'new' products, are the genuinely new or are they rehashed old products?
The only new product that I'm aware of is a supposed Mach4 ready controller, and it's absolute s*********t, it does not support Mach4s GUI, just wxMach, what a joke. XHC have no interest in
fixing it, and I don't know how many people who've bought only to have to throw them out as junk. Seems to have tailed off recently, as most people do enough research to understand they are being ripped.
Craig
-
:( :( :(
So, the good reliable brands are?
-
Hi,
the reason that I am dubious about the controller is that g31 is and has to be a realtime procedure.
When a probe event occurs the motion controller must immediately decelerate the moving axis. This immediacy, measured in a few tens of micro seconds is required to avoid over travel.
The controller must have that feature built, or programmed in, in order that it can happen almost automatically.
It is not sufficient for the controller to report back to Mach, it would take some tens of milliseconds to do so, then Mach would calculate the deceleration trajectory
and communicate that to the controller whereon it will go into the motion buffer, commonly several hundred milliseconds in duration. The delays are such that overtravel would
be excessive.....and that it what you describe.
I would concur that XHC has been in the market long enough that I would have expected it to support g31, even if development has ceased this realtime support should have been
part of the controller function for many years now. Your description of what is happening rather suggests the the controller does not have that critical realtime support.
Craig
-
Hi,
sorry, forgot to mention the good ones:
I use an Ethernet SmoothStepper ($190) by Warp9 TD in the US. Others are:
UC300,and UC400 (about $150) by CNCDrive in Hungary
57CNC (about $150)by PoKeys in the UK (I think?)
CSMIO (about 600Euro) by CSLabs in Poland
HICON (starts at $600) by Vital Sytems in the US.
All of these devices have complete and well sorted plugins for Mach3, and all have a Mach4 plugin but in some cases a less complete set of realtime supports. All, should have g31....that's one of the most basic.
Of them the Ethernet SmoothStepper and the HICON have the most complete Mach4 plugin, with both companies committed to supporting Mach4.
The UCnnn products are made by CNCDrive, and they have their own software, UCCNC, and good it is too, but naturally they support their own software before investing too much effort in supporting the competitors (NFS)
software.
Craig
-
And I use a cncdrive uc100 which also supports probing.
-
your controller may support G31 what is enough for a "simple" probing, but am pretty sure
it is not supporting the update of the var's 2000-2002.
-
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!
-
https://www.machsupport.com/forum/index.php?topic=35226.0
-
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/s2. I regularly probe at a feed rate of 100mm/min or 0.0017m/s. The overtravel is:
OT= 1/2 x a x t2 where a is the acceleration and t is the time taken to stop. The time to stop is:
tstop=vinitial/a
=0.0017/1.5
=0.00067 seconds
OT= 1/2 x 1.5 x 0.000672
=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
-
Well, you might like to read this thread:
http://cncdrive.com/forum/viewtopic.php?f=2&t=288
...which includes this reply from CNCDrive:
"cncdrive wrote:
I can't say anything about if it matters in Mach3 or not, I did not use it for a too long time now and I can't remember how this is handled in Mach3.
In the UCCNC as I wrote the probing input is not polled, but a software interrupt is generated on the 2 probe pins on the edge which is set to the active one.
The sofware interrupt means that the code exacution inside the microcontroller jumps to the interrupt service routine as soon as the microcontroller detects the set edge on the probe pin.
This is a hardware microcontroller feature and happens immediately without any delays, the only delay, the max. 50nsec is because the return address to return back after the interrupt has to be saved to the stack prior to doing anything else and then the coordinates are read, these takes upto 50nanoseconds with the 200MHz CPU frequency microcontroller in the UC300ETH, because one micro CPU cycle is 5nanosec and it can take upto 10 CPU cycles to do the mentioned things.
After these are saved the saved coordinates are sent back to the computer via the ethernet, so the user can access them.
It is another thing when and how the probe stops, that can be a problem if the probing is too fast, it does not influance the programmatic measurement accuracy though, however of course too fast probing could cause the switch to jump/prell and could cause the machine to shake and also the axis stops a bit further since it has to stop, but again the probe coordinates are already saved when the axis stops, so these things are no more UC300ETH, but machine and sensor dependents."
So at least one motion controller works this way even if Mach doesn't.
As for the probe delay, I need to get a copy of the Renishaw presentation I referred to but meantime you might refer to the RMP60 installation guide. This product has a programmable filter delay to help reject false triggers which can be set to 0, 10, or 20ms. Clearly this has to be taken into account in the probing routine. I'm not sure if that is in addition to the 5ms. The presentation dealt with a trial comparing delays between their stand alone wireless system and one using a 5G private local network. There's a lot of interest in using private 5G in factories to connect automation systems and if you have machine tools with probes it's an obvious question whether you could fit a 5G modem in the probe and use the local infrastructure. The 5G network was tested against the 5ms criterion of the stand-alone system - not surprisingly it failed. Also worth looking at their application note TE412 comparing 1-touch with 2-touch probing, which points out that some controllers poll hardware inputs perhaps every 4ms which introduces an inherent uncertainty averaging 2ms into the probe response in addition to the sensing delay.
As to why there is a delay, as I mentioned the RMP60 uses a frequency-hopping system for robustness in an electrically noisy environment, and to distinguish between different probes in the vicinity (say a tool setter and a probe on the same machine). Inherently in such a system it would take at least one complete FH sequence to decode a trigger signal, so there's bound to be a delay.
I was impressed by the fact that the probe can operate whilst rotating at up to 1000rpm!
-
Hi,
maybe UCCNC operates differently however when operating with Mach a UCnnn motion controller latches data when the axis is stopped.
Read the excerpt I posted earlier, that is the instructions o0ffered by NFS as to how a motion controller must handle probing in
order to work with Mach, UCnnn works with Machs g31 probing therefore it must comply with the procedure set out by NFS.
The two motion controllers that I've use are the ESS and Machs parallel port, and both operate identically, namely the trigger event
causes the axis to decelerate to a stop and then the data is latched once still.
Why don't you do some experiments and probe a surface at varying approach speeds. Another way to illustrate what's going on is to as an experiment,
reduce the z axis acceleration down to 10% of normal and try probing again. In both of these circumstances I would expect the the overtravel
change and therefore the position latched into Mach. If you choose to experiment with a fast approach speed AND a low acceleration you will end up with
overtravel and you'll need some springiness in either the probe or the probed surface to avoid damage.
Craig
-
I'm sure you're correct Craig about how Mach works, and of course since there's a plugin for each controller presumably NFS can define how probing should work. But the way UCCNC works with its native controllers still seems much more satisfactory to me as it registers the ACTUAL point at which the probe triggers.
I've enquired on the UCCNC forum and it does not have a probe delay parameter so one still has to use slow probing to minimise the error.
I attach the Renishaw slide I referred to.
-
Hi,
well if you ask me I would say that probe is junk, 40um overtravel before the motion controller detects the event????
Irrespective of whether the position is latched at the probe event OR after the axis is decelerated to a stop....40um is BS.
I probe printed circuit board blanks, inevitably there is some bow or warp that needs be accommodated, the copper layer is only 35um thick
and I require the tool to cut that 35um but do not want it to cut into the substrate. In practice you do have to have some cutting into the substrate to
reliably cut the 35um copper layer. In practice I use a cut depth of 0.08mm, or 80um. With the corrections provide by probing the surface prior to cutting
this results in 100% reliable cutting of the copper layer without unduly cutting into the substrate. For this to work I require the probing to be
10um or better....40um would screw me.
If I used a probe that had 5ms latency then I can kiss making PCBs goodbye.
I have read that much of the latency that these RF probes exhibit is because it can take 5ms for the radio link to synchronise. If it were a straight wired
probe (like the only type I can afford) then there would be no latency, or at least reduced to 10us or less.
Craig
-
But that's why the delay is precisely controlled. If you know the overtravel since you know the feed rate and delay you can simply correct the value. These probes are used in machines with tool changers and have to be wireless. Also in certain operations the probe is rotated, which is slightly difficult with a wire connected! You would have no problem using this probe for autolevelling, you just need to add or subtract the 40um from the measured values in the probe macro. The radio link is much faster but in a noisy environment with several machines and Wi-Fi etc you have to have a robust protocol with retransmission and padding to give a known total delay.
When it comes to machine probes I think I'll accept Renishaw's point of view as they have just a little experience in the topic.
-
Hi,
Reinshaw have a magnificent reputation, and prices to match. Certainly the circumstances of use preclude the use of a wire, and if
you can alter the probe result after detection then you can recover the accurate position.
Can you afford one of these things? Even second hand?
My probe circuit is two wires with clips, one going to the spindle nose, and the other to the PCB blank, cost....near zero, and repeatability of
several um.
Craig
-
Er. which part?