Cumulative error in Z axis Arc Moves

[Lohmeyer]

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

[Karl_T]

If it makes any difference, I haven't got a clue.
Karl

[Lohmeyer]

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

[Karl_T]

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

[Lohmeyer]

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

[Karl_T]

Originally Posted by Lohmeyer 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. ... ' 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

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

[Lohmeyer]

\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.

[Lohmeyer]

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.

[Karl_T]

Originally Posted by Lohmeyer 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. ... 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

[Lohmeyer]

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

[Lohmeyer]

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

[Karl_T]

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.