Re: RESOLVED: EMC is poorly designed and implemented.

["Keith Rumley" <dscadcam-at-yahoo.com>]

Keith,

 Some good points you've got there. My comments interspersed.

>   I'm an old gray haired assembly hacker and cycle counter with some
> experience in closed-loop motion control.  I have been investigating
> EMC, principally emcmot.c and have come to the conclusion that EMC is
> poorly designed and implemented.

1. Certainly interdependencies are not well documented, but the modular
approach is basically sound.

2. EMC consists of GUI (Tcl/tk),  EMC (mot,NML,task, rcs_impl) and the
Real-time Control System. EMC was written to demo the RCS, I believe. (My
short synopsis - RCS providing control framework language, EMC doing an
implementation of a machine control app.) The GUI by Ray H. written to
improve the X-windows interface. (which it did, thanks, Ray!)

>   What I see in the implementation is wasteful, redundant access to
> I/O ports, lack of insight into floating point speed considerations,
> poor factorization into subroutines and far too many scattered ifdefs
> for reliable code.
>
>   Modern motion control should be adaptive, using Kalman filters, and
> state-space or observer predictor methods. EMC by design uses PIDs,
> which are from old 1930s analog computers.  PIDs tuned via Ziegler
> Nichols methods are inherently prone to oscillation and instability.
> (The zeros don't cover poles, or drift into right hand plane, etc
> as the dynamics of the plant change with temperature and load.)


3. EMC is entirely open to adaptation, provided #1 is figured out. (not an
easy one). Also, servo implementation came first, I believe. Stepper
(extsmmot) was a later hack, probably one of the reasons for looser code.

A more structured development course might help the scattered #ifdefs...

4. EMC's PID tuning methods are most affected by user variable settings in
EMC, usually a level above the servo amp/motor/resolver internal PID. As far
as I can tell, 'observer' methods aren't there, but do have the
'feedforward' implementations  to use should someone write one.(
(torque/velocity/x) The pidtune app may also have comparator methods of
doing that, but not tied into EMC.

5. No temperature referencing exists in EMC, or load reference, per se. Many
machine tools don't do the temperature thing, yet. The RCS can be extended
to take temp, load, etc.

>   A 8-bit 6502 or 8051 running at 1 MHz could do a nice job of running
> stepper motors in 1978.  Without double precision, 32-bit integers
> or 800MHz clock rates.  Servos were harder, but still possible.  Today
> yoy can go to http://www.jrkerr.com/ and buy a PIC-STEP or PIC-SERVO
> with software for a reasonable price with software that'll get you up
> and running twenty times faster than EMC.

6. How do these implement G-code? (OK, I'm lazy, and haven't browsed over
there...)

>   Floating point is very fast these days, but it still takes time.
> Even on Pentiums, double precision floating point is about half as fast
> as single or integer arithmetic.  Divides take about twice as long as
> multiples.  A subroutine call takes about as long as an integer add
> for each 32-bit parameter.  These are ballpark figures, much affected
> by caching, out-of-order and speculative execution.

7. Ahem, your assembler is showing. :)


Regards,

 Keith Rumley



_________________________________________________________
Do You Yahoo!?
Get your free -at-yahoo.com address at http://mail.yahoo.com