Re: STG2 - Latest Developments

[Jon Elson <jmelson-at-artsci.wustl.edu>]

JohnDRoc-at-aol.com wrote:

> Yes, it's fast, it's definitely an industrial-strength milling center.  It's
> not a humming sound it's more like a grinding or laboring sound.  It runs in
> my mind that it ran more "freely" before, but it might just be a result of
> the compensation - maybe I didn't notice when it was slamming back and forth.

Well, I still think it is what I saw, but maybe not.  Does the sound change
at different jog speeds?  What is your P parameter in the axis setup, in fact
what are all your parameters in there?  If the P gain is set too high, it could
cause rough operation.  Yes, it could be tuning of the servo amp, too.
I found it was best to run with a conservative P, I and D set to zero, and
a small value on FF1, about 5.0  This gave me really minute following error
and quite solid position holding, without any instability.

>  I think the next step is going to be working with the logging program, to
> determine the fine tuning of the amps.  Then, I think I saw in a post from
> Fred, that there is supposed to be a program that helps come up with the PID
> values.

Unless they've done some serious repair in the PID department, the I and
D are programmed wrong, and do not do anything useful.  Unfortunately,
Fred is a little pedantic, and apparently the course he took on controls
theory gave a steady-state, or at least one quadrant, definition of PID
algorithms, and he can't get out of that one-quadrant mindset.  The problem
is this is a motion control problem in all FOUR quadrants.  And, Integral
history from when you were in a different quadrant is not only irrelevant,
but makes your solution MORE inaccurate, instead of reducing error.
But, pedantically, because you are SUPPOSED to use the entire history
of the system, he holds that you MUST use the entire history, even if
it fails to perform the necessary goal.  The Derivative term probably
works, in the general sense, but since this is a quantized system, and
in slow motion there are so few encoder counts per servo cycle, the
Derivative term from each encoder cycle has WAY too much quantization
noise to perform well.  It needs to be smoothed a bit, but again, pedantically,
Fred refuses to see this as a problem.  To him, it doesn't matter whether
the system performs well at a machining task, as long as it is mathematically
pure.  Fortunately, they put in the FF0, FF1 and FF2 terms, which are
both mathematically pure, and of great use.  FF1 is actually better than
some combination of I and D, because it can respond BEFORE error
develops, as in a rapid acceleration of the system from rest.  The I
term won't know what is going on for minutes, because it is taking the
average of millions of tiny errors past, and due to the quantization, you
can't set the D term very high, or the system gets unstable.  As long
as the servo amps are well behaved, just using P and FF1 has worked
VERY well for me.

So, I don't know what the auto-tune program will do with those parameters.
If good, it will also find them to be unhelpful, and leave them close to zero.

>  I also need to figure out how to send a reference signal to the
> spindle inverter, from the STG board.

This is apparently not working yet, but is definitely on the list.  One of the
things to be dealt with is that there are at least 3 ways to do this.

1.  A spindle run digital I/O signal, and a bipolar spindle speed signal.

2.  A spindle forward and a spindle reverse signal, and a unipolar spindle speed

3.  A spindle run and a spindle direction signal, and a unipolar spindle speed

So, some extra functionality needs to be coded into the routines that
parse and handle the .ini file parameters to make a choice of these
modes, which depend on how the spindle drive needs it.

 In communicating with Will, there
shouldn't be any loss in functionality between Dec and newer versions.

Hmm, yes, but in fact, there are things that don't work.  I have been
running about 7 versions of EMC on my computer with no trouble for
over a year, but the Mar and May 2000 versions crash very quickly
on the same machine.  It is clearly not the hardware, as when I put
20-Dec-1999 back on, it returns to total reliability.  It even runs
through thunderstorms with the lights blinking without trouble.

The newer versions have an improved backlash compensation that
works, but the whole setup is not reliable.  Others have had the
same problem, but we don't know why.

Second, all versions since freqmod came in (I think) have this
'humming' problem, which is clearly a fluctuation in velocity
commands when it is supposed to be smooth.  It may be some
sort of 'beat' between different sections of the code running at
different dispatch rates, or possibly a fluctuation in the servo
interval, which could be related to CPU speed or other DEEP
hardware characteristics that RT-Linux thinks it is finessing, but
isn't.  At about the same time this appeared, the RT-scheduling
was changed from rescheduling interrupts to continuous interrupts,
and there may be some side effect.  Hmm, good project for a
logic analyzer.  If the servo cycle was delayed every time the trajectory
routine is run (which, by default is every TENTH time) it could
SURE cause this exact problem.  If the interrupts overflow, it
could kill the system, too, if there isn't a graceful way to handle
this.  The self-rescheduling way will never overflow the interrupt.
I think I'm onto something, here, and will have to do some testing.

If Fred or Will happen to read any of the above, their comments
would be appreciated - I hope I haven't made Fred mad at me!

Jon