Reply with QuoteIf it makes any difference, I haven't got a clue.
Karl
Cumulative error in Z axis Arc Moves
As I said in my other thread, servo tuning has finally allowed me to isolate the real problem on my CNC mill - a cumulative error in Z axis arc moves.
My machine is a 3 axis knee mill conversion using Camsoft v16.7 and a Galil DMC-1842 PCI card. My encoders are on the end of the motors, not linear scales.
Basically, arc moves with a Z component (G02/G03 X.. Y.. Z.. I.. J..) are causing a cumulative error. I'm spiraling down into a pocket G03, cutting the pocket at that depth, then spiraling deeper, cut pocket, spiral down, cut, etc.
Each time I spiral down, the Z depth is exactly 0.01mm short of the commanded z depth. E.g. if I command to -18.15mm, it stops at -18.14mm. Furthermore, the Z depth error is cumulative. By cumulative, I mean the first Z spiral is 0.01mm short. The second spiral is 0.02mm short, and so on. See table below.
Commanded Actual Diff
-17.063 -17.053 0.010
-22.750 -22.730 0.020
-28.438 -28.407 0.031
-34.125 -34.084 0.041
-39.813 -39.761 0.052
-45.500 -45.438 0.062
When the pocket is done, I do a G00 Z25.0 to rapid out of the hole, and instead it rapids to 25.062. That's what finally made me realize it's not a servo error. I mean it went to exactly 25.062 - the exact same error that I had at the bottom of the pocket. I'm in absolute mode (G90), but it's like Camsoft command the Galil card with relative moves.
Next I try the same code using Single Step and the error goes away. Single stepping somehow resets the accumulated error.
This is just one example. Pretty much any G02/G03 arc move with a Z component has this accumulating error. The error can grow to exceed the POSERROR limit and it will not cause a stall or position error.
My TOLERANCE is 0.0005" (0.0127mm). Thinking this was a math error for the arc commands, I changed TOLERANCE to 0.0001" (0.0025mm). No change to the result.
So, something about arc commands (G03, G02) is causing cumulative errors in Z. Linear moves (G00, G01) don't add to the error, but the error follows the move.
What am I missing?
Thanks,
Mike
Similar Threads:
If it makes any difference, I haven't got a clue.
Karl
Thanks Karl. If you don't have a clue, I might be in trouble.
The previous owner of the machine worked with Camsoft on this issue for a while but never got a resolution. I don't know how deep they got into it. I was told the problem was there when I bought the machine, but wasn't able to find the problem until now as the servo problems masked it.
I"m not sure if the read out error is a real error or not (I haven't cut a part and measured to see if the error is real, or just a mistake on the position read out on screen). That's important because it's odd that the position is off by more than the POSERROR value (affected by TOLERANCE) yet the machine doesn't stall.
If you command a Galil card to go to X, it goes there, period. The only way it can be told to go to X, and have it actually to go X + some error is due to servo problems (which I have solved), or because you actually told it to go to X + the error and didn't realize it (an error in the math converting mm measurements to encoder counts). My G-code.fil isn't doing anything different from the default examples provided by Camsoft (i.e. it's just passing the G03 and G00 commands to Camsoft via CCW and RAPID commands), so I assume there is either a math error, or a parameter setting screwing things up. Or maybe a bug, but for now I'm giving Camsoft the benefit of the doubt on that because G03 X.. Y.. Z.. I.. J.. commands are just too common and simple. If it was a bug, someone else would have found it already - I hope.
Thanks,
Mike
Say, I just remembered, I rewrote G2 and G3 to threadmill. Here's my code:
Karl
\775=0 'cancel G81-G89 canned cycles
IF \830=8THEN\833=1 'flag to check for window closing in MDI
DISPLAY4 {f}
DISPLAY5 {s}
TIME CYCLE;\4
DISPLAY7 \4
RUNTIME \4
DISPLAY8 \4
'changes below allow for helix motion, now 3D arcs won't work
IF \144=1 THEN CW x;y;z;i;j; 'arc in XY plane
IF \144=2 THEN CW x;y;z;i;;k 'arc in XZ plane
IF \144=3 THEN CW x;y;z;;j;k 'arc in YZ plane
-----G2
\775=0 'cancel G81-G89 canned cycles
IF \830=8THEN\833=1 'flag to check for window closing in MDI
DISPLAY4 {f}
DISPLAY5 {s}
TIME CYCLE;\4
DISPLAY7 \4
RUNTIME \4
DISPLAY8 \4
'changes below allow for helix motion, now 3D arcs won't work
IF \144=1 THEN CW x;y;z;i;j; 'arc in XY plane
IF \144=2 THEN CW x;y;z;i;;k 'arc in XZ plane
IF \144=3 THEN CW x;y;z;;j;k 'arc in YZ plane
-----G3
PLANEXY
\144=1 'XY plane
-----G17
PLANEXZ
\144=2 'XZ plane
-----G18
PLANEYZ
\144=3 'YZ plane
-----G19
I think you hit upon the thing I was about to go test. See below for my G03 code in Gcode.fil. My CCW command has i;j;k, but with G03 X.. Y.. Z.. I.. J.., the CCW k value is undefined. Seems like a blaring issue. Is that why you made the change?
What about the comment in your code that says now 3D arcs won't work? That's just because you no longer have a CCW command with i, j and k, right? That's easy enough to add as well, but I don't think I'll ever do 3D arcs. Just 2D arcs with a Z component.
Thanks!
Mike
My G03 code...
'circular move
DISPLAY1 \803
DISPLAY2 \11
DISPLAY3 \10
DISPLAY4 {f*(\73/100)}
DISPLAY5 {s*(\74/100)}
\603=1:\600=0:\601=0:\602=0
[ACTIVE CODES] ' Update display
' 3D Mode
IF\237=1THEN CCW x;y;z;i;j;k:\775=0:\776=0:EXIT
' 2D Mode
IF\237=2THEN CCW x;y;0;i;j;k:\775=0:\776=0:EXIT
-----G3
Originally Posted by Lohmeyer
3D arcs: Camsoft has some incredibly powerful ability to to arcs and vectors in 3D space. heady stuff. But I don't need it.
chase that \237 variable. Not sure what this is doing.
Karl
\237 indicates if 2D mode is enabled. In 2D mode, all Z moves are suppressed. It's both for testing your program in air, and because in 2D mode you can use the quill to manually drill or tap a hole. I never use it.
Nope, removing k from my G03 (CCW) commands changed nothing. Karl, why again did you do this? Was there a specific problem you were trying to fix.
I started looking at anything on the system related to arcs. ARCFACTOR? I have always had it set to 1000. But, CNCSetup says that's too high. The docs say 1 to 300 is the range because anything above 300 and the PC will start slowing down on arc moves (over taxing the CPU). OK, that was true maybe 15 years ago. I have set it at 10000 and seen no slowdown. Why is it set to 1000? Because at 300 or below, my arc cuts are horrible. Broken up into too many line segments. Anything less than 700 is useless. At 1000, I get good clean (round) arcs.
So, I changed it to 300, 100, and 10000 and ran a test. This had a radical difference on the amount of Z error. With 1000, I saw 0.01mm error with each complete group of spirals. At 100, I was getting 0.04mm error with each group of spirals. At 300, I got a different amount of error. At 10000, it went up to 0.167mm error for just one group of spirals. That means after cutting the entire pocket and rapiding back to 25.0mm, I end up at 26.336 mm due to the cumulative error!! There was no proportional correlation in the amount of error vs. the ARCFACTOR.
Again, no POSERROR stall due to exceeding TOLERANCE.
What else in the Camsoft system (what settings or files) can affect arcs? I'm beginning to think this really is a bug with Camsoft.
I cleaned up all my commands to not use uneeded parameters. Here's what can happen. Specify a K value earlier in the program. Later issue a G02 command. Sence you didn't have a K in your command line, the control will use the earlier K value. Try this while cutting air, with a large K you'll get an arc in 3D space.
My understanding of how all these really complex moves are obtained. Keep in mind I'm also talking about all the matrix manipulating, scaling and rotating that can be done. Break the tool path into very small line segments, do the advanced kinemetrics, then issue thousands of very small line segments to the control.
By changing the ARCFACTOR to a value they told you not to do, I guess the segments are now too small. It is possible that something like math rounding errors are now significant causing the effect you see.
If I were you, I'd bet Rueben and Ernie a beer that I found an undocumented program feature. I should warn you, I've done this several times. So far, I've won no beer.
Karl
Re: ARCFACTOR
What I don't understand about ARCFACTOR is the docs say don't go over 300, because larger than 300 and your computer will slow down due to lack of computing power. I think this is an old statement relating to computers from the '90's. I"ve seen no slow down with ARCFACTOR 1 to 10,000. Maybe large ARCFACTOR values are bad for multi-axis (8 axis) systems, but for my 3 axis system, > 300 is fine in terms of not slowing down.
The other problem with ARCFACTOR is the line segment thing you talk about. At 300 or below, the line segments are so big that my circles have clearly visible line segments (i.e. unacceptably horrible surface finish). At 1000, I get excellent circles with no visible line segments. So, I'm surprised they suggest numbers as low as 100 or 300 for ARCFACTOR because in my experience, these low ARCFACTOR values are useless for any real machining purposes.
I assume the problem is related to math errors (math precision). That's why I tried different TOLERANCE values which affect the accuracy of Camsoft's math, and a different ARCFACTOR which also changes the math. I tried ARCFACTOR 300 and 100, and the problem persists and even got worse. So it's not a matter of using too large of an ARCFACTOR.
Re: cleaning up your G02/G03 commands
Yes, I think I have seen problems like you describe where an arc in the XY plane all of a sudden magically arced in the YZ plane (a little different than what you are talking about, but I get the concept). I realize it was probably due to an undefined k value (and maybe math rounding error). In my case, this was a result of increasing TOLERANCE to a large value as a test, but the point is, having undefined k values could be disastrous. It shocked me at first, but makes complete sense when thinking how TOLERANCE affects the math. That's why I'm surprised that changing TOLERANCE had _no_ effect on this problem (the Z error problem).
For now, I'm going to change all my programs to use Zig-zag ramp entires into pockets instead of spiral ramp entries (i.e stop using any G02/G03 commands with a Z component).
Thanks,
Mike
Something I just realized...
I'm not just seeing errors in the Z value. I also get errors in X and Y with my arc commands, but I don't notice them because the error is small (less than TOLERANCE). I.e. they are acceptable within my given TOLERANCE. This is fine and expected due to math rounding/precision. That's part of why we have a TOLERANCE value. The problem is the compounding of error with multiple arc commands in succession. That's a bug. Remember, I said if I single step, the error no longer compounds? Single stepping resets the math, and the compounded error goes away. That should happen without having to single step.
Why does the Z error become a problem while X and Y do not? Because I'm cutting circles in the XY plane, so X and Y are moving back and forth, and the error averages out with each back and forth movement. It is compounding, but since one time it's a + error, and the next time it's a - error, the end result averages out (within my TOLERANCE). But, the Z cut is all in one direction (minus Z). So the error compounds.
I can test this. If I do a line of arcs where X is always increasing (a line of half circles connected end to end in the X direction), I should see the X error compound just like I'm seeing in the Z direction. I'll have to try that later this week. I can't work on this anymore right now. I need to get some real work done.
Regardless, there is a second problem (which is actually the same problem). Earlier I described where I had a 0.063mm Z error at the bottom of my pocket, and then I rapid (G00) to 25.0mm. But my final position was 25.063mm. Not only is the error compounding during the arc commands, but it doesn't reset itself when switching to a linear move. What should happen is the error should reset between every move. And, that's exactly what happens when I single step through the program. When single stepping, I don't get the compounding Z error, and when I rapid to 25.0mm, I stop at exactly 25.000 mm +/- 0.001 (well within my tolerance).
So the error of an individual arc command isn't the problem. That's normal. The problem is the compounding of the error over multiple moves.
Regards,
Mike
I'd make these suggestions.
Put your ARCFACTOR back in a range recomended by Camsoft.
Investigate adding the SMOOTH command with the SPLINE option to your arc codes. Turn SMOOTH back off after the arc. This should make your arcs real nice.
Getting one parameter way out of whack can cause problems all over.
I've looked at SMOOTH a couple times. It's a nice feature. But according to the manual, the SMOOTH options FASTMODE, SPLINES, and NURBS are only for linear (G01) moves, not arcs. So this won't affect my arc commands. If I had Mastercam output my arcs as linear segments, then yes SMOOTH SPLINES would make a difference. Might be interesting to play with, and this may be a work around, but not a final solution. I need G02/G03 commands to work.
The only other parameters I can think of that might affect the arc error are my BLEND, NEXTMOVE, and SLOWDOWN settings. I have the following:
BLEND = -250
NEXTMOVE = 0.005
SLOWDOWN = 100 (100% - meaning no slow down)
I understand what these parameters do, but I don't know much about the ramifications of changing them - especially how they might affect arc commands. Also, how ARCFACTOR is influenced by these settings. Are there other settings that affect arcs?
Thanks,
Mike
Mike,
What is the exact ratio between your ballscrew pitch and your encoder count per rev? Is there a half count required to make the ratio work exactly?
First you get good, then you get fast. Then grouchiness sets in.
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
If you can send of the G code you're using to make the spirals , we would like to check out what you're describing.
Below is an explanation a few of the topics that were brought up in order to clear up some of the conjecture.
1. The only internal command necessary to make a G2 arc for a 3 axes mill/router would be
CW x;y;z;i;j;k
Use CCW for G3
Either G2 or G3 can add up to 8 axis of coordinated motion while swinging the arc. Add as many axis call out letters you choose up to 8. The 4th thru 8th axis can be linear or rotary motion and will corrdinate with the arc being swung but only the first 3 axis will swing an arc.
CW x;y;z;i;j;k;a;b;c;u;v
The i;j;k being the arc's pivoting center. All 3 i;j;k values would be required to make a 3D arc, you may skip the k when doing normal 2D arcs.
2. A single CW or CCW command alone is enough to cut a standard 2D arc, 3D arc, arc on a canted titled plane, helix or spiral based on the mathematical values entered. The "G17" PLANEXY, G18 PLANEXZ or G19 PLANEYZ commands automatically flip the arc on edge. The MATRIX command will add tug, pull, twist, stretch, rotate and tilt the arc too.
3. The CW and CCW commands are also influenced by how many encoder counts or steps were defined in one unit (inch or mm or degree)
4. The ARCFACTOR setting plays a role in the fineness of sine/cosine algorithm. The bigger the value the finer the arc smoothness. However, at some point where the internal sine/cosine formula generates numbers smaller than one whole encoder count or step move will have no affect on accuracy but can greatly affect the feedrate and smoothness on how the arc cuts since the extra code being sent to the motion card will bog it down. Increasing the ARCFACTOR will not produce math errors just no accuracy benefit and may even slow down the cutting speed or produce a stop & go , rough jittery cutting surface finish if the motion card can't process the extra data as fast as you're cutting feedrate.
Today's computers are able to calculate high ARCFACTOR's mathematically very fast depending on the Windows version, CPU speed and how busy the PC is doing other things somewhere on average between a setting of 100 to 1000. Where the default value of 300 creates a 0.0002 scallop height and 1000 is less than a 1/4 micron. When the accuracy of the ARCFACTOR value exceed the distance 1 whole encoder count or step can achieve based on the quality of the position feed back hardware you're using then no extra accuracy benefit is seen. Rather a degradation of cut quality and cutting feedrate will out weight the benefit.
5. The logic command SMOOTH is for splines and has no effect on arcs
6. See QUESTION 164
Our machine is losing position. The more moves we make the more the position error accumulates.
In the current version there are about 1 1/2 pages on several possible reasons for this. Your version may have less. Some older manuals do not mention the fractional encoder box check box in this help section. If not then leave the check box un-checked on the MOTION SETTINGS page regarding fractional encoder counts.
7.If none of the above explanations and solutions helps you and since you mention Z is the axis accumulating the only thing left is that the values being passed are creating an arc on an ever so slight tilt on a canted plane in minutes or seconds of a degree which in building up as you repeat them. If we find this is the case you can tighten your TOLERANCE value. This would only occur if the TOLERANCE is set larger than the amount of the depth of each helix or spiraled cut or in the opposite case smaller than what +/- one encoder count or step can move.
We would like to be sure and test your G code.
Tech Support
CamSoft Corp.
support@camsoftcorp.com
PH 951-674-8100
Fax 951-674-3110
PC Based CNC Control For The Machine Tool CNC Retrofit And CNC Controller OEM Market
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
Posting Permissions
