Re: RESOLVED: EMC is poorly designed and implemented.

[Maximilian HEISE <max.heise-at-gmx.net>]

Hello Keith,

I think everybody on this list really appreciates your research on the EMC 
code. The problem is, most of us how have used EMC know of at least a few 
"dark corners" in the code that should be changed, but nobody fixes them.
I reason for that is that most of us like spending our time with their 
friends, families and sports/books/movies/chicas/hobbies( put your favorite 
here. And yes, well EMC is actually a hobby for most ) rather then sitting 
around a computer 20h a day ( 4h for sleeping ... ). At least these are my 
priorities, student life can be so exciting ........

If you have the time and if your willing to spend it on the EMC project go 
to it, really. I found Fred and Will as well as all of the other users 
helpful in any way, if you have questions, ask them, if somebody knows the 
answer you will get a reply.

>   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.
Why don't you make the changes to the code and post diffs to the list, or set 
up a CVS account, or even better if the changes are really big a new CVS 
branch that can be later merged back into the mainstream code ?
Start with small changes, bigger ones never get completed ( of course only 
speaking of myself ;-) )

>   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.)
I am sorry, until now I haven't even heard of Kalman filters. And I spend 
endless hours/nights tuning PIDs from my Prof. examples and old tests to 
prepare for exams. So blame my Prof. for not even mentioning them. Do you 
have pointers to some literature on the web to get some information about 
Kalman filters so that I can make my own opinion ?
Yes Ziegler-Nichols can only serve a starting point for tuning PIDs manually, 
but after all this is what bode and nyquist diagrams and matlab/simulink and 
all the other stuff are for. Do you have some matlab/simulink files/examples 
about kalman filters ?

> 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 agree.

>   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.  
Yes I agree.

> 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.
Yes this behaviour is required here in Germany, but isn't it obvious that 
limit switches shut down power to the motors. Maybe I am already to used to 
think this way that I cannot even imagine somebody not doing it. 
Perhaps this should be included in the documentation under Safety as 
something like this:
******************************************
For your own safety always connect the limit switches
to e-stop in a way that will reliably shut down main power 
to the motors/spindle when hitting e-stop.
******************************************


>   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.
I agree.

>   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.
I agree.

> You may consider this the ranting of a dinosaur or as constructive
> critism - as you choose.
It is constructive critism for sure, but please put your insights to good use 
and change the code, I'd be glad to test it, and I am sure many other will be 
giving it a good try too.

Regards
Max

-- 
Max Heise <max.heise-at-gmx.net>
Student Mechatronik/Automatisierungstechnik FHT Esslingen
PGP public key from:
http://www.fht-esslingen.de/~mahemt01/pgp50i.pub or any keyserver