Re: freqmod.o in EMC started, now questions

> From: "Tim Goldstein" <timg@...>
>
> OK, with the EMC Board of Knowledge online I have gotten EMC to come up

with

> the new freqmod.o module for steppers and it does run the machine with
> faster movements.

Good!

> Now for the questions:
> What does the P and the FF1 parameter you play with really do?

P is Proportional gain. I'd start out with about 50 here and maybe go up to
100 or so. FF is Feed Forward gain, set all these to 0 as it causes problems
with the current release.

> Why do my steppers sit and buzz after a move? I actually think I know this
> answer which I think is the steppers are hunting back and fourth about
> .0002" trying to get where the feedback position matches the expected
> position, but the steps are not fine enough to get a zero difference. I do
> see the actual positions oscillating a few ten thousands. So, the real
> question is not why, but how do I get them to just sit still when at rest?

You are correct. Insert this additional line (marked MGS) in
/usr/local/nist/emc/src/emcmot/emcfreqmot.c at about line #2256:

/* interpolate */
oldJointPos[axis] = jointPos[axis];
jointPos[axis] = cubicInterpolate(&cubic[axis], 0, 0, 0, 0);
/* MGS */
jointPos[axis] = jointPos[axis] -
fmod (jointPos[axis], (1 / emcmotStatus->inputScale[axis]));
/* MGS */
jointVel[axis] = (jointPos[axis] - oldJointPos[axis]) /
emcmotStatus->servoCycleTime;

/* run output calculations */
if (GET_AXIS_ACTIVE_FLAG(axis)) {

This additional line quantizes the commanded position to a multiple of your
step size.

I also had a problem with changing the direction bit at the same time the
step output changed. This is due to the direction bit setup time
characteristics of my stepper drivers and may not affect you. I modified
freqfunc() to look like this (about line #2679 in emcfreqmod.c):

static void freqfunc(int i)
{
unsigned char output = 0;
int axis = 0;
unsigned int delaymag[FREQ_AXES];
char delaysign[FREQ_AXES];
unsigned int delaycount[FREQ_AXES];
char toggle[FREQ_AXES];
char reversal[FREQ_AXES]; /* MGS */

for (axis = 0; axis < FREQ_AXES; axis++) {
delaymag[axis] = 0;
delaysign[axis] = 0;
delaycount[axis] = 0;
toggle[axis] = 0;
reversal[axis] = 0; /* MGS */
}

while (1) {
for (axis = 0; axis < FREQ_AXES; axis++) {
if (enable[axis]) {

/* MGS */
if ((delay[axis] < 0 && delaysign[axis] == 0)
|| (delay[axis] > 0 && delaysign[axis] == 1)) {
reversal[axis] = 1;
}
/* MGS */

if (delay[axis] == 0) {
delaymag[axis] = 0;
/* leave sign as it was */
}
else if (delay[axis] < 0) {
delaymag[axis] = - delay[axis];
delaysign[axis] = 1;
}
else {
delaymag[axis] = delay[axis];
delaysign[axis] = 0;
}

if (delaymag[axis] < delaycount[axis] /* programmed f increased, so go
faster now */
|| --delaycount[axis] < 0) { /* counter expired */
delaycount[axis] = delaymag[axis];
if (!reversal[axis]) {
toggle[axis] = ! toggle[axis];
}
if (delaysign[axis]) {
output |= (0x01 << (axis << 1));
}
else {
output &= ~(0x01 << (axis << 1));
}
if (toggle[axis]) {
output |= (0x02 << (axis << 1));
if (!reversal[axis]) {
if (delaysign[axis]) {
freqcount[axis]--;
}
else {
freqcount[axis]++;
}
}
}
else {
output &= ~(0x02 << (axis << 1));
}
reversal[axis] = 0; /* MGS */
} /* end of if (expired) */
} /* end of if (enable) */
} /* end of for (axis) loop */

pptDioByteWrite(0, output);

rt_task_wait();
} /* end of while (1) */
}

Fred is at this ver moment working on some other changes that will double the
number of frequency steps available which should further improve the
smoothness of accel and decel.

After changing this file, cd to /usr/local/nist/emc/src/emcmot/ and enter the
command:

make PLAT=rtlinux_09J all

There may be a few warnings, but no errors if your editing was accurate!

> Last question is how do the [TRAJ] and [AXISX] CYCLE_TIME relate to the new
> settings? Should I just set them to .01 and .001 and leave them alone or is
> their value in playing with these along with the P and FF1 parameter?

I would (in the following order):

1. Reduce the value of this number at about line #292 in :

static int PERIOD = 20; /* fundamental period for timer interrupts */

With a 350MHz P2 I can go down to 12 and still start up reliably. If you make
this too small, EMC won't start. It'll complain about "can't communicate..."
You'll have to recompile (as above) for each change and then try it. This
will end up in the .ini file eventually.

2. Reduce [AXIS] CYCLE_TIME as low as possible (see what this does for you, I
haven't played with this parameter yet, but I'm going to soon).

3. For the time being I'd set [TRAJ]CYCLE_TIME to 10x [AXIS] CYCLE_TIME.

A couple other things:

1. MAX_VELOCITY is really the maximum velocity you can command with F... It's
possible for the maximum step rate to exceed this limit if following error
builds up. Since in a servo system (and that's what this is now regardless of
the type of motor) the control loop tries to close the gap between actual
position and commanded position by applying more drive to the motors. In a
system with a Servo To Go card the DAC voltage is increased, in this new
version of the stepper code the output frequency is increased. If you have
problems with stalling (I did), you can clamp the maximum frequency output in
both directions of travel by setting MAX_OUTPUT (+ direction) and MIN_OUTPUT
(- direction) for each axis in unit/sec. This gives individual control over
the axis speeds which is something that has been requested in the past.

2. You probably will want to set the MAX_FERROR up to something like 100
while you play with these other variables to keep from popping up "following
error" warning windows.

3. Get the spreadsheet:

http://users.erols.com/mshaver/stepfreq.xls

and plug in your values for PERIOD and INPUT_SCALE to calculate what
frequency steps you can produce. This will give you some plateau values to
use for MAX_VELOCITY, MAX_OUTPUT, and MIN_OUTPUT.

4. If anyone is wondering what part of the EMC system is being worked on now,
this is it!

Matt