Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: zone023 on December 13, 2010, 03:49:30 PM
-
Hi All,
I am encountering a problem when running a button script.
It is a fairly simple probing script, for measuring flatness of a surface.
There are a few dro's involved for surface size, grid size, etc.
The script uses some Do Until...Loops to scan a surface for flatness in a regular grid.
Scanned XYZ values are written to a textfile.
For instance, on a surface of 270 x 400 mm with a 20mm measuring grid about 300 points are beeing probed.
This takes about 10 minutes.
During this scan my machine sometimes acts strange, it looses steps and is running irregular.
Also, when the probe hits the surface "G4 P.25" is used, a pause to allow for writing values to the textfile.
About 1 in every 100 times the pause is skipped, the probe backs off immediately to go to the next piont.
XYZ Values are written okay though..
Is there some explanation for this strange behaviour?
I never loose steps when running g-code.
I can run complex programs without a problem.
So, is there a way to scan with a g-code file?
Can XYZ values be written to a textfile while using g-code?
I mean g-code in a .NC-file, not g-gode in a button script.
Thanks for helping!
Rich
-
You can run a g-code G31 loop using a sub and some # variables then jump into a custom macro to write the data to a file, that way the moves are all native g-code.
Graham
-
Hi Graham,
I have no idea how to do what you say.
I will have to find out how to use # variables...
Are there enough variables available to store 300 to 500 xyz values? (thus 1500 values)
Some searching and reading will help, I guess... ???
Is it normal that g-code in a button scrip is executed like described, with irregularities?
Does this happen because the VB-script is interrupted by windows, or something like that?
Thanks for helping!
Rich
-
I would write each coordinate to an array, then when the process finishes, write the array to the file. Updating an array is much faster than writing to file. Just write the file once.
FWIW...I've seen the same issue with G4 pause commands being skipped and it wasn't from a button script. It is while running a g-code program. It's usually the first one in the program. No idea what causes it, but it hasn't been enough of an issue to spend a whole lot of time on.
-
Hi,
Missing the pause isn't the real problem...
It just also happens on an irregular basis.
The real problem is missing the steps...
When I scan say 300 points on a surface, in my opinion the machine should make a repeated regluar sound... probe and step to the next piont.....probe and step to the next point....probe and step to the next point....etc...
But the sound is not regular, like it hessitates sometimes...or sometimes it seems to react faster, skip a pause..
As said, the machine normally never looses steps when running a .NC-file.
Loosing steps while probing from a vb (button) script only occurs on the y-axis.
The y-axis is driven on both sides. It has dual motors, master and slave setup.
My guess for now is that, because of the irregularity, master-y and slave-y are not receiving their commands simultaneous.
Thus tension builds up in the y-axis and steps are lost... ( I hear a "bang" when loosing steps...)
.NC-files, even with repeated operations, never give me this problem... :-\
Thanks again.
-
I thought it might help posting the script... :D
Option Explicit
Dim POX As Single '-- probe offset X
Dim POY As Single
Dim TD As Single '--Tip Diameter
Dim shiftZ As Single
Dim Xwp As Single '-- X work at probe position
Dim Ywp As Single '-- Y work at probe position
Dim Zwp As Single
Dim minX As Single
Dim minY As Single
Dim maxX As Single
Dim maxY As Single
Dim sizeX As Single
Dim sizeY As Single
Dim stepX As Single
Dim stepY As Single
Dim borderX As Single
Dim borderY As Single
Dim ProbeFeed As Single
Dim RapidFeedXY As Single
Dim RapidFeedZ As Single
Dim Datum As String
POX = GetUserDRO(1501)
POY = GetUserDRO(1502)
TD = GetUserDRO(1503)
RapidFeedXY=GetUserDRO(1615)
RapidFeedZ=GetUserDRO(1615)
ProbeFeed = GetUserDRO(1505)
Xwp = GetOemDRO(800) + POX
Ywp = GetOemDRO(801) + POY
sizeX = GetUserDRO(1601)
sizeY = GetUserDRO(1602)
stepX = GetUserDRO(1605)
stepY = GetUserDRO(1606)
borderX = GetUserDRO(1610)
borderY = GetUserDRO(1611)
minX = borderX
minY = borderY
maxX = sizeX - borderX
maxY = sizeY - borderY
Datum = Format(Now, "yyyymmdd")
Datum = Datum & "-" & Format(Time, "hhmm")
If GetOemLed (825)=0 Then
Open "c:\mach3\scan\SCAN-" & Datum & ".txt" For Output As #1 ' Open to write file.
MsgBox ("Probe will move. Make sure work area is clear. Probe-tip must be about 10mm above work!")
Code "G90 G1 X" & minX - POX & " Y" & minY - POY & " F" & RapidFeedXY 'Move to border
Code "G91 G31 Z-15 F" & ProbeFeed
While IsMoving()
Wend
Code "G4 P0.25"
Call SetDro (2, 0 + (0.5 * TD))
Code "G4 P0.5" 'Pause for Dro to update.
Code "G91 G1 Z5 F" & RapidFeedZ 'Probe backs off 5mm
While IsMoving()
Wend
Code "G90"
Code "G4 P0.25"
Code "G91 G31 Z-10 F" & ProbeFeed
While IsMoving()
Wend
Code "G4 P0.25"
shiftZ = GetVar(2002) + (0.5 * TD)
Code "G4 P0.15" 'Pause for Dro to update.
Code "G91 G1 Z5 F" & RapidFeedZ 'Probe backs off 5mm
While IsMoving()
Wend
Code "G90"
Code "G4 P0.25"
Xwp = GetOemDRO(800) + POX
Ywp = GetOemDRO(801) + POY
Zwp = 0
Write #1, Xwp, Ywp, Zwp
If Xwp + stepX < maxX Then
Code " G91 G1 Y" & stepY & "F" & RapidFeedXY
While IsMoving()
Wend
End If
Xwp = GetOemDRO(800) + POX
Do Until Xwp + stepX > maxX
Code "G4 P0.1"
Code "G91 G31 Z-10 F" & ProbeFeed
While IsMoving()
Wend
Code "G4 P0.05"
Xwp = GetOemDRO(800) + POX
Ywp = GetOemDRO(801) + POY
Zwp = GetVar(2002) - shiftZ + (0.5 * TD)
Write #1, Xwp, Ywp, Zwp
Code "G91 G1 Z5. F" & RapidFeedZ
While IsMoving()
Wend
Do Until Ywp + stepY >= maxY
Code "G4 P0.1"
Code " G91 G1 Y" & stepY & "F" & RapidFeedXY
While IsMoving()
Wend
Code "G4 P0.1"
Code "G91 G31 Z-10 F" & ProbeFeed
While IsMoving()
Wend
Code "G4 P0.05"
Xwp = GetOemDRO(800) + POX
Ywp = GetOemDRO(801) + POY
Zwp = GetVar(2002) - shiftZ + (0.5 * TD)
Write #1, Xwp , Ywp, Zwp
Code "G91 G1 Z5. F" & RapidFeedZ
While IsMoving()
Wend
Loop
If Xwp + stepX < maxX Then
Code "G4 P0.1"
Code "G90 G1 X" & Xwp + stepX - POX & "Y" & minY - POY & "F" & RapidFeedXY
While IsMoving()
Wend
Else
Code "G91 G1 Z5. F" & RapidFeedZ
While IsMoving()
Wend
Code "G90 G1 X" & minX - POX & "Y" & minY - POY & "F" & RapidFeedXY
While IsMoving()
Wend
End If
Loop
Code "G90"
Close #1
MsgBox ("Scan File saved as c:\mach3\scan\SCAN-" & Datum & ".txt")
Else
Code "(Probe is active, check setup and try again)"
Exit Sub
End If
-
THere are several thing working aginst you with your approach.
The VB is not in any way synced with the Gcode side so the VB can endrun your Gcode if time is short(and will). and vise versa.
The G4 does not control the wait for the VB side Sleep() is what you use to control the wait in VB. AND it will be nessesary to use it to help control the flow and wait for updates.
THe G31 is very reliable and accurate IF used like Graham stated entirley in Gcode.The G31 "does" have a report modual that saves all your points to a file AND is very reliable. (;-) Then that part is control from inside of MACH.
I have probed many 100,000s of points with G31 and the save point files with no errors > Can't say that for the VB side using the G31. Sooner or later something gets out of sync.
Just a thought, (;-) TP
-
Just a note M40 opens the saved points file and G41 closes it when you are all done.
-
The real problem is missing the steps...
You may be missing steps because the PC is busy writing to a file after the G4 finishes. Mach works best when it is the only thing using PC resources. In other words, the file write may be taking longer than the G4 is allowing. You could try increasing the G4 dwell, but personally, I wouldn't be trying to write the file on every G31 move. Store the coordinates in an array, then when the routine finishes, open the file, dump the array to the file and close the file.
-
Hi TP and rrc1962,
Thanks for the reply.
I think I am encountering the problems TP describes.
The way the machine acts while running a VB script already gave me the feeling things are not in sync.
As a quick solution I will try writing results to an array while probing and write the array to a text-file when finshed.
But I think probing with .NC g-code will work better after all...
That means I have to learn how to write g-code subs, I guess.
Also writing to variables is new for me... ???
Of course I will do some searching myself, but is anybody willing to share an example??
Thanks again!
Rich
-
Here is how I would do it, all you have to do is create the M1234 macro to store the points in an array and a M1235 macro to store it after you finish.
Graham
%
G21 G40 (standard setup lines)
#1=[20.] (spacing in X)
#2=[20.] (spacing in Y)
#3=10 (no of points in X)
#4=15 (no of points in Y)
G00 G43 H3 Z25.00
G00 X0 Y0 (set position of first hole/point as X0 Y0)
M98 P1000 L#4 (repeat #4 times)
M1235 (store the vb data array)
M30
O1000 (this bit moves Y axis)
M98 P1001 L#3 (repeat #3 times)
G91 (set to move incremental)
G00 Y#2 (do move to next line)
G90 X0 (set to absolute and go back to start of line)
M99
O1001(this bit moves X axis)
M98 P1002 (call probe sub)
G91 (set to incremental)
G00 X#1 (do move to next point)
G90 (back to absolute)
M99
O1002 (this sub probes)
G00 Z1.
G31 Z-5. F200.
M1234 (call vb macro to store values in array)
G4 P500
G00 Z1.
M99
%
-
Graham, you are the MAN!!
Reading around a little I already found some info.
I was beginning to see the light.....far away...
But this brings it all together! THANKS!
It seems that you can do a lot more with g-code than it looks like on first hand.
My CAM software spits out g-code to easy to study it in depth.
I know what G0 G1 G2 etc is..that's it...
But now it shows that it might be VERY usefull to make it your second language... ;D
I will try to do the "writing"-macro's myself. ::)
Thanks Again!!
Rich
-
No problem, if you want to test run the code just change the G31 line to something like G01 Z-1. F200. and Mach3 will simulate the moves for you.
Graham
-
I have already loaded the code into Mach in offline mode to see what is happening.
M1234 and M1235 are still missing...
Regarding to the M1234 (probe values to array) macro I have some questions.
Will a variable like #3 be "carried over" to the macro? (this to set the size of the array)
How to avoid the array is re-declared every time the macro is called?? Do I need to use the ReDim Preserve command?
And just to be sure..I guess I need GetVar(2000) etc to write the values to the array...??
Pfff...I am just a dutch truckdriver in daily life... so please be (stay!) kind to me... ;D
-
The GetVar(n) command will allow you to pick up the # variables in VB, n being the # number you require. xstep=GetVar(1)
You may have to set up another M code to initialise the array as global at the start of the g-code.
I have not used the redim command in Mach3 so I would not like to say, maybe somebody else has and will chip in on the subject.
Make sure you save the macros in the macro folder for the profile you are using.
Graham
-
Thanks again, Graham.
You've more than put me in the right direction.
Now it is time for me to stop asking and start working. :D
Rich
-
I'm thinking the scope of the array will not extend beyond the instance of the script it resides in. In other words, every time you call M1234, you'll be dealing with a new empty array rather than one array with global scope. In VB.NET I would just create a global array but I'm not sure if that's possible in VB script. If, as Graham suggests, you are able to create a global array via a macro, I'd be curious to see how you did it. Not saying it can't be done, just never tried it and curious if it's possible.
-
I am not sure it can be done ether but if not there are other ways to do it.
Graham
-
Hi,
Working on the macro's... but no results... :-[
As rrc1962 already suggests I am having trouble letting the array survive when the M1234 macro is left for the next probing step.
I have tried making another macro to start with, M1233
It only contains the following line:
Public arrXYZ(999, 2) As Double
First, I found that
Dim arrXYZ(GetVar(3) * GetVar(4), 2 ) As Double
is not allowed. GetVar is giving an error here.
Also, in M1234
arrXYZ(0,0)= GetVar(2000)
Will not work. The array is not recognized as such.
I am happy things are not easy, life would be boring :-\
But how are others writing their probing-values???
I hope I find the answer before someone gives it to me.
Nothing would be left of my selfrespect ;D
-
The mach saved points file works fine open it with g40 assign a name then close with g41 when you are all done probing. Each time the probe trips it auto writes the values of xyza to the file. That way there is little to no VB interaction to cause problems.
But that is just my approach, (;-) TP
-
Huh??
My Mach MDI Page / g-code explanation button says:
G40 = Cancel cutter radius compensation
G41 = Start cutter radius compensation left
I guess I am confusing things ???
-
TP,
I think you mean M40 and M41..
I will give it a try...
-
That's it!! M40/M41 works!!
Everything is easy when you know how to do it...
But this is even easy when you don't know... ;D
No VB script required!!
Thanks Graham, BR549 and rrc1962 for helping me!
-
YEP yall got it right what do you need me for(;-)
(;-) TP
-
I am very happy to be able to do some smooth probing now...
Only one minor problem left.
With the button script I wrote it was possible to do surface probing in G68 mode. ( that was the one and only good part of the script... :D)
Using the probing G-code Graham posted together with the M40 command like BR549 suggested it is also possible to do the probing in G68.
But X and Y position are saved in MACHINE coordinates. :(
Is there a way to store them in WORK coordinates??
Because...I love G68..... ;D
Throw something on your table, probe position, START.
I am going trough all this because I have written a small program to adjust g-code depth (Z) to a non flat surface.
This is for engraving acrylic or pcb's with a v-bit...and keep trace width constant...
It works, but I need a good probing grid of the surface for interpolation of the new depth.
Preferably while probing in G68 mode... ::)
Rich
-
At the end of the run you could have a VB macro post process the file and recalculate the XY positions by subtracting the work offsets from the machine position.
Graham
-
I already thought about that. But not only the offset should be subtracted but also the G68 rotation should be corrected.
Math on highschool is already 25 years behind me...
I have had some practice while writing the program for depth correction.
G1 G2 and G3 moves are broken into smaller parts to adjust height along the way.
So I think I will be able to do what you suggest, but it will be a lot of work with my lack of experience...
No problem, but a waste of time when an out of the box solution exists.. (Like M40 for writing the probe-data....;D)
Rich
-
THe g68 is great to correct part to material. But is it really neccesary for probing(;-) probing the points generates an object in 3d space Once you have the points you need to process the points back to a cut file correct? That would be the time to do a standard correction back to square. In the cam side just rotate the part back .
That is how the big boys do it.
HUM I don't remember the probing storing points in Mach Coords. That would not really make sense.
The probe can be corrected for tip radius in the XY planes so the exact centerline stored as points. This saves a lot of time in the cam side trying to correct for tip radius and correct the size of the part.
Just a thought, (;-) TP
-
Hi TP....Mr. Little here.... :D
I don't know what the big boys do...Had to figure it out by myself...
That's why I want to do the following. :-\
First the setup.
I have a probe permanently mounted on my Z-axis.
The probe can be brought in place when needed by activating an accurate pneumatic actuator.
The offset probe > mill is a fixed value in X and Y.
Say, I want to engrave an acrylic sign.
Acrylic is no way flat. On a 10 mm thick sheet thickness can vary about plus or minus 0.4mm.
When engraving with a v-bit at 0.1 mm depth this means a very thick trace...or no trace at all...
The acrylic sheet already has the size needed for the sign.
Only the engraving has to be done.
What I do is:
- Place the acrylic on the table
- Probe position in X and Y.
- Set G68 rotation and offset
- Z-Probe the surface of the acrylic sheet (Till now with my crappy button script..)
- Pull the Z-probe results and the original g-code for the engraving through my "z-control" program.
- Load the z-adjusted g-code into Mach
- Zero tool
- Start... :D
It might be an unusual approach...but I like it...can't help it...
I did a dry run with the probing g-code Graham posted, machine offline.
Just lowered the number of points a little, replaced the M1234 and M1235 macro with M40 and M41.
When I probe in G68, 1 degree rotation, offset x10 and y10 I get the following results.
10.00000,10.00000,-5.00000
29.99687,10.34688,-5.00000
49.99375,10.69688,-5.00000
9.65000,29.99687,-5.00000
29.64688,30.34375,-5.00000
49.64375,30.69375,-5.00000
9.30000,49.99375,-5.00000
29.29688,50.34063,-5.00000
49.29375,50.69062,-5.00000
8.95313,69.99062,-5.00000
28.95000,70.34063,-5.00000
48.94687,70.68750,-5.00000
Probe offset can be ignored, this is a dry run (as if the probe is in the centre of the mil/spindle).
Probe (M40) X and Y are not the same as the (red) X Dro and Y Dro.
X and Y Dro show "integers" as probing points, like:
0.000, 0.00
20.000, 0.000
40.000, 0.000
etc
The X and Y values M40 "writes" in G68 mode, in my opinion, really are machine coords. :(
Offset and rotation are known, so machine coordinates can be "calculated back" to work coordinates.
But for me that will be a lot of work/reading.
So I was looking for a way around...still impressed by the simplicity of M40..! :)
Rich
Or actually D I C K, but this is ****ed away quite often, on English sites... ;D
(Mr Little is extra funny in this case!)
-
I see your point for engraving (no pun intended)
NOT sure the need for G68 probing (;-) It is VERY easy to rotate a part square to the table(;-) But each his own on that one(;-)
OK the solution is to RefALL to the same 0,0 point as your Fixture offset. That way it all reads and writes the same values(;-)
The machine corrds and users corrds will be exactly the same.
I wonder IF you could apply the surface offsets to the axis correction map or possible use the data to create an offset table of Gcode variables.
MAYBE a wizard to compile all the info into a gcode file???
Just trying to keep it simple and trouble free, (;-)TP
-
Move RefAll to fixture 0,0 is indeed a solution, didn't think about it....
(And when I think about it, rotation also has to be taken in account :()
Taking the time and write some vb code to calculate machine coords to work coords is more elegant, I think.
And that has to be done only once...
I wonder IF you could apply the surface offsets to the axis correction map or possible use the data to create an offset table of Gcode variables.
Not sure what you mean with this, english is not my native language...
The "z-control" program I wrote functions on itself, outside Mach.
My knowlege of vb is far better than my knowledge of Mach, it's variables, g-code etc
So I thought this was the way to go.
All I need is text-file (CSV, Like M40) of the surface scan and the original g-code.
Those are loaded in z-control.
z-control outputs adjusted g-code with interpolated Z's and broken G1 G2 and G3 parts.
It works. Even with G68 and my crappy button probing script.
Or with Grahams probing g-code and M40 without G68.
-
IF you have a working solution that is all that matters(;-)
(;-) TP
-
Yeah...but I want it all... ;D
Graham's smooth probing g-code, M40/41 AND G68...
Time to start coding and make something to convert machine to work coordinates...I think..
-
Hi,
I have written a small piece of code.
This to convert the machine x and y coordinates mach3 stores with M40 in G68 mode to work coordinates.
Now I can do exactly what I want....smooth surface probing in G68 mode... ;D
I like to thank the contributors to this post for helping me!
Rich
-
Don't forget us when you make your millions, I like fast Jags, Terry and the other guys might like one too. ;)
Graham
-
:D
Until now it only costs...
Wonder if I am going to pass break even ever... :D
-
How about taking a minute and posting in the Mach tool Box section on HOW you did it and post the code you did it with???. It sounds cool and I am SURE someone else could use it as well.
YEP a new Jag would do, (;-) But as long as your are happy I am happy,
Sling some chips
(;-) TP
-
Hi TP
I will consider that.
The code is all in a separate program, written in vb6. It functions on its own, outside mach3.
First of all it has to be refined, there still is some "testing-code" left that has to be removed.
Secondly, I foresee some problems with international use..
Here in Holland we use comma as a decimal separator.
In the US a point is used.
I have some point to comma converters in the program that might become a problem...
I don't know where you are, maybe I can send it to you first to do some testing....when ready...
Rich
-
I have not left the building yet... one more question... :D
As said, the code I have written functions outside mach3. Including the scan-grid correction part( to correct values M40 writes for probe-offset, G68 rotation, etc.)
I think it is better to do the scan-grid correction INSIDE mach3, with a macro at the end.
Now I have to carry over to many data (probe-offset, G68 offset and rotation) by hand to the program I have written.
This increases the risk of mistakes, and it is inconvenient also...
When it runs in a macro it can read Dro's for getting required data.
What I would like to do is open the DigFile M40 creates again and do the necessary calculations.
So... Is there a way to "remember" the filename M40 asks for?
I have tried giving the file a numeric name and save the name in a variable.
Someting like this:
'M40
Dim strFile as string
SetVar(10, Question (" Scan number? ( = name, MUST be numeric)"))
strFile= "C:\" & GetVar(10) & ".txt"
OpenDigFile(strFile)
In this way I would be able to open the file again using varable #10.
But it doesn't work... :-\
Any ideas for a working solution??
Thanks!
-
I don't believe you can use the opendigfile for that type of use. I would use the normal VB convention to open the text file.
Now IF you were just adding more points thru more probing then opendigfile IS the way to do it.
Comma delimited files are NOT a problem(;-)
(;-) TP
-
Yes.. I want to use normal VB convention to open the textfile. (Not OpenDigFile)
But I don't want to see the OpenFile Dialog twice.
First to set scan-file (M40) name. Then to open it again, in a macro, to do corrections. (Probe-Offset, etc)
So I am looking for a way to "remember" the M40-filename in a string.
So that it can be found by the end-macro for corrections.
Because #-variable IS remembered I came up with idea of the the numeric filename..
But it doesn't work.
Of course, I can let the macro ask for the filename again with an OpenFile Dialog.
But typing the same filename twice in a short period....hhmmm
Computers are here to automate, aren't they... ;)
-
OK now I see where you are going. I guess I was out daydreaming.
Unfortunately Art did not leave us that option.His OpenDigFile() does not allow an external aurgument to be used as a filename (;-( .
The only wildcard IS you could record the date/time then look for a file opened after that parameter in the saved directory???
Welcome to the Close but no CIGAR club, Been there many times. (;-) TP
-
No problem...me explaining not clearly enough could also be the case... :D
The idea of recording date and time certainly is creative and useful.
To keep it working all the scans must be in a directory only for scans.
That may not be a problem
Do you think asking Art kindly makes sense...?
Changing recorded X and Y cooordinates, in G68 mode, from machine to work would also be great... ::)
-
Sorry but Art is not involved with Mach anymore other than driver bugs that may pop up.You would have to talk to Brian at Artsoft.
Could not hurt to give it a try.
(;-) TP
-
And now would be the time to ask as Brian is rewriting Mach so it may be easier to add such things at this time.
Hood
-
OK, I will ask Brian soon. Thank you, Hood
In the meantime will I keep grid-corrections inside my vb6 progam.
TP, I will send you my "Z-control" program for testing when I think I can show it to someone... without feeling like a moron...
That might take 2 more weeks or so... ;D
-
Here is another thought (;-) Make the program USE the same exact name up front each time for example lets use PntFile.txt
When you open the M40 dialog use that name. Then YOUR script will know what name to use to apply the corrections. When your script is done THEN let it save out the file as another name. LOAD that file name to be engraved
Then delete out the original file name Pntfile.txt so it will be available next time.
You can also use a OEM DRO to store the last used filename(number) then increment the NEXT new name(number) +1 to use for the next file name.
That wil semi-automate the process
Just a thought, (;-) TP
-
Now that's simple but SMART!!
Use the same filename everytime...
There is no use in storing the scan-files anyway. Each surface is unique, of course.
The engraving g-code is the part that is reused again and again..
Thanks!!
-
Make sure you send us a picture. Yours is a project that MANY people in the past asked for(;-)
A way to correct for surface irregularities when engraving.
(;-) TP