RE: RESOLVED: EMC is poorly designed and implemented.

["Barry E. King" <beking-at-cox.net>]

Very interesting observations.  Some are certainly valid.  I do not see any
evidence that would merit a complete rewrite or redesign however.  There do
not appear to be any architectural arguments below, but rather, solely
implementation issues that you take to task.  The PID servo algorithms could
certainly be replaced by something else.  Using integer math in place of
some floating point operations do not suggest a rewrite.

A few notes, however.

EMC does not preclude the use of hard limit switches.  In fact, many highly
recommend their use.  That is left to the user of this completely free and
open non-commercial system.  My system is wired in exactly this way and
would stop even if the limit switches were not read by EMC.

The use of hardware interrupts, a scarce resource on the PC at best, would
require additional hardware and appropriate driver software.  Although
reasonably cheap ISA boards can be made at home, proper PCI boards for
modern computers are much more daunting for most and certainly more
expensive.  Hardware hacks can be had (like the NMI and single step
debugging switches added to some of my old systems). Most will not do this
nor are not up to that sort of attack on modern motherboards.  In either
case it would defeat the purpose of using an EMC-like solution in the first
place.

As to Mr. Kerr's most excellent offerings, I am not sure exactly what you
mean by "twenty times faster".  If you mean have a working CNC machine, that
obviously is not true.  I had my EMC installation operable from a virgin
linux install within a day (actually a few hours).  It took a few hours in
addition to sort out some glitches due to an inconsistency in my system.  It
took far longer to wire up and test steppers, drives, various switches and
sensors, power supplies and the like.

I also presume you do not mean motor system speed, since that too is
obviously not true at least not in all cases.  It ultimately depends upon a
number of factors, most as you are no doubt aware have nothing to do with
the host software.  Perhaps Mr. Kerr's latest stepper offerings will indeed
crank out the 200 kHz worth of pulses required by my stepper driven mill in
order to achieve twenty times faster speeds (that would make for 300 IPM,
probably a little much in my case).  I should check again, I suppose, since
I am certainly interested in any PICs that will pull that off.  For now I am
quite happy with 30 IPM rapids on my small mill.

As to the PID routines, I am certainly out of my element here.  In any case
I would suggest that observed results dictate whether it works or not.
Theory is great but only useful if it has a solid foundation in the
practical.  It seems to me that many people are using the PID routines to
drive both servos and steppers and they do not seem to be complaining about
producing erratic parts.

Perhaps someone should start a poll to be sure.

Based on the comments below it seems to me that it boils down to the use of
floating point over integers for certain specific operations and perhaps the
efficiencies of the coding in a few areas.  There does appear at first blush
to be some merit in those conerns.

I presume by your taking the time to comment that you actually have some
interest in improving the state of EMC.  It escapes me why one would bother
to write such detailed account if this is not the case.  Perhaps you could
head up a series of contributions to make EMC better.  I am certain your
contributions will be well received and appreciated.  You will no doubt
receive assistance and support if it can be demonstrated that there will
indeed be measurable material improvements.


Regards,

Barry

> -----Original Message-----
> From: emc-at-nist.gov [emc-at-nist.gov]On Behalf Of Keith R. Bolson
> Sent: Wednesday, January 30, 2002 9:30 PM
> To: Multiple recipients of list
> Subject: RESOLVED: EMC is poorly designed and implemented.
>
>
>
> RESOLVED: EMC is poorly designed and implemented.
>
>   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.  I don't mean to be discourteous,
> but you do not have a good solid product, nor will you without
> a major redesign.  I will support this conclusion in the following.
>
>   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.)
>
>   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.
>
> Look at the source code (30-Jan-2002 sourceforge emcmot.c), lines 2422ff
> the polling of the max and min limit switches, home and axis fault bits.
> This is within the for loop on line 2373
>
> L2373    for (axis = 0; axis < EMCMOT_MAX_AXIS; axis++) {
>
>   This is very poorly done, the exact same bits are read repeated,
> (for extsmmot.c) with over one microsecond per pptDioRead inportb
> call.  That's (3 axes)*(4 switches)=12 microseconds, with 16 us
> listed as the max.  Only one 1 us read is required.  The situation
> is worse in stgmod.c, where 4 bytes are read, so it takes 48 us.
> Folks - i/o port access always takes over a microsecond, regardless
> of the speed of your i86 processors.  Reading the same bits
> repeatedly in critical code is foolish and wasteful.
>
>   I believe the choice to poll and debounce these switches within
> the motion loop (rather than, say, using a hardware interrupt or
> a slower emcio task read and debounce), is a very unwise design
> decision.  Furthermore, American and European safety standards
> REQUIRE that hard limit switches bring the machine down even if
> the processor is non-functional.  Meaning the limit switches, through
> a dumb relay, should drop main power to the motors.  So on commercial
> machines, you don't need to check the limit switches, you'll E-stop
> if you hit them.  As implemented here, EMC is likely to be HAZARDEOUS
> to the health of its users.
>
>   And there's this over-dependence upon double precision numbers
> when single or integers will suffice.  For example, in the external
> interface to stgmod.c, passing the raw encoders and dacs as double arrays,
> when they're integers on all hardware, doubles the subroutine call time,
> and then the subroutine itself has to convert it to an integer.
>
>   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.
>
> So code like on emcmot.c line 2397,
>   L2397  if (fabs(emcmotStatus->input[axis] -
> emcmotDebug->oldInput[axis]) /
>   L2398      emcmotConfig->servoCycleTime > emcmotDebug->bigVel[axis]) {
> Would be 50% faster if expressed as
>   M2397  if (fabs(emcmotStatus->input[axis] - emcmotDebug->oldInput[axis])
>   M2398      > emcmotConfig->servoCycleTime * emcmotDebug->bigVel[axis]) {
> But both servoCycleTime and bigVel are infrequently changed - on a
> explicit command, dump bigVel for bigLeap=bigVel*cycleTime and have
>   N2397  if (fabs(emcmotStatus->input[axis] - emcmotDebug->oldInput[axis])
>   N2398      > emcmotDebug->bigLeap[axis]) {
> which by my tests on 233 and 800MHz machines, would take about a third
> as long.  I see the "debounce bad feedback" has been changed, it indicates
> a very serious hardware error which still is not logged or reported.
>
> You may consider this the ranting of a dinosaur or as constructive
> critism - as you choose.
>
> God Bless America, President Bush and our fighting men and women.
> --krb
>
>
>