Re: STG2 - Latest Developments

[Will Shackleford <shackle-at-cme.nist.gov>]

> Date: Wed, 12 Jul 2000 02:23:40 -0400 (EDT)
> Originator: emc-at-nist.gov
> From: Jon Elson <jmelson-at-artsci.wustl.edu>
> To: Multiple recipients of list <emc-at-nist.gov>
> Subject: Re: STG2 - Latest Developments
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> Content-Transfer-Encoding: 7bit
> X-To: emc-at-nist.gov
> MIME-Version: 1.0
> 
> 
> 
> 
> 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
> 
> 
> 



I talked with Fred briefly yesterday about this. 

As far as the humming is concerned, He suggested removing the rounding that he
added in January.

The original comment from the RELEASE_NOTES for this was:

2. Quantization of the computed trajectory points to the nearest input
resolution, either encoder counts or stepper steps. This solves the
hunting problem, where the system calls for a position that is between
two steps and therefore won't ever get there. Thanks to Matt Shaver
for this one also.
 
If you want to try this find the line

#ifndef NO_ROUNDING

in emcmot.c  and change it to either

#ifdef STEPPER_MOTORS

to round only in emcfreqmot  or just

#if 0

to never do rounding.

I tried this on the bridgeport and it had no noticeable effect, but the 
bridgeport was pretty quiet in the first place, atleast compared to the other 
machines in the same shop.


-- Will








---------------------------------------------------------------
William Penn Shackleford III			shackle-at-nist.gov
National Institute of Standards & Technology	Tel:	(301) 975-4286
100 Bureau Drive Stop 8230  			FAX:	(301) 990-9688
Gaithersburg MD  20899  USA
http://www.isd.mel.nist.gov/personnel/shackleford/
Office Location: Bldg. 220 Rm A253