Undershoot of toolpath in axis?

I'm in the process of tuning the PID loop on the X axis of a 96 knee mill (11x52, about 3500lbs, brushed DC servo motors with ball screws, Mesa 5i20 w/ 7i33). During my testing, I've come up with a set of coefficients which seem to work very well, holding the axis to within 0.001 or 0.002 inches of the target position (so says realtime running average statistics that I'm monitoring).

I have a test program that makes 2 passes on a circle, and 2 linear back-and-forth passes, and while it's running these operations I'm watching the ferror to see how well the PID coefficients are doing.

When running Axis on my test program, it appears to be undershooting the toolpath, then continuing on to the next command. (per the small arcs between the straight line and the circle).

I find that when I slow down the feedrate override, the issue will disappear (going all the way to the base of the circle), however when I increase the feedrate override, it will undershoot more and more. You can see the short white lines in the attached image, I was expecting those to be red, having been passed over with the tool.

I would expect that emc should wait for the first line of g-code to get to it's target position before executing the following line of g-code, is that not the case? Perhaps there's more to the dynamics of the system going on here?

Any ideas?

Thanks,
-d



Test Program:
%
F30
G1 X0 Y0
#1 = 0
O101 while [#1 lt 100]
G2 X1 Y1 R1
G2 X2 Y0 R1
G2 X1 Y-1 R1
G2 X0 Y0 R1
G2 X1 Y1 R1
G2 X2 Y0 R1
G2 X1 Y-1 R1
G2 X0 Y0 R1
G1 X2
G1 X0
G1 X2
G1 X0
#1 = [#1+1]
O101 endwhile
%



X-Axis config
[AXIS_0]

TYPE = LINEAR
MAX_VELOCITY = 120
#MAX_ACCELERATION = 18
MAX_ACCELERATION = 3
BACKLASH = 0.000
FERROR = 0.015
MIN_FERROR = 0.005

INPUT_SCALE = 30000

OUTPUT_SCALE = -1.000
OUTPUT_OFFSET = 0.0
MAX_OUTPUT = 1.0

MIN_LIMIT = -33.1
MAX_LIMIT = 33.1
HOME = 0.000
HOME_OFFSET = -2.9
#HOME_SEARCH_VEL = -0.50
HOME_SEARCH_VEL = 0
#HOME_LATCH_VEL = 0.10
HOME_LATCH_VEL = 0
#HOME_USE_INDEX = YES
HOME_USE_INDEX = NO
#HOME_IGNORE_LIMITS = YES
HOME_IGNORE_LIMITS = NO

# PID tuning params
#DEADBAND = 0.000015
DEADBAND = 0.00001
P = 160
I = 80
D = 4
FF0 = 0.000
FF1 = 0.5
FF2 = 0.0
BIAS = 0.000

You might want to look here ..

www.linuxcnc.org/docview/2.4/html/gcode_main.html
From that page...
" G61 Exact Path Mode

G61.1 Exact Stop Mode

G64 Best Possible Speed

G64 P- (motion blending tolerance) Q- (naive cam tolerance)

G61 visits the programmed point exactly, even though that means temporarily coming to a complete stop.

G64 without P means to keep the best speed possible, no matter how far away from the programmed point you end up.

G64 P- Q- is a way to fine tune your system for best compromise between speed and accuracy. The P- tolerance means that the actual path will be no more than P- away from the programmed endpoint. The velocity will be reduced if needed to maintain the path. In addition, when you activate G64 P- Q- it turns on the "naive cam detector"; when there are a series of linear XYZ feed moves at the same feed rate that are less than Q- away from being collinear, they are collapsed into a single linear move. On G2/3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 P- tolerance the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end). those lines are then subject to the naive cam algorithm for lines. Thus, line-arc, arc-arc, and arc-line cases as well as line-line benefit from the "naive cam detector". This improves contouring performance by simplifying the path. It is OK to program for the mode that is already active. See also Section [->] for a discussion of these modes. If Q is not specified then it will have the same behavior as before and use the value of P-."

Rick G

Hi guys, thanks for the response... That was in fact the issue... I have never played with those variables in EMC and in fact didn't know they existed... After changing it to a G64 P0.002 it held right on the line that I wanted it to...

Thanks!
-dave