Re: Where is EMC going?

[Ray Henry <rehenry-at-up.net>]

Peter

Thank you for opening this subject.  On several ocasions I've heard people 
express the need to overhaul it.

Many of the thoughts in your post were the topic of several discussions at 
NAMES-02.  The EMC users group addressed this problem during one very long 
dinner at it's second annual meeting. We must think up a better acronym than 
emcug -- and a better way of encouraging membership and attendance than 
recruiting from those emc'ers around late Saturday during the NAMES 
exhibition.

There is a lot of truth to the notion that the EMC was written using the 
"brute force" approach.  I know that my part of it is.  It has also been 
written, revised, and added to over quite an extended period of time.  All of 
this has led us to recognize that the code may be convoluted, difficult to 
understand,  and nearly impossible to work on in concert by a group of 
developers distributed around the world.  

Further we recognized that rapid evolution in the hardware and software 
commonly used by the EMC and the RSCLIB requires that we constantly play a 
catchup rather than a leadership role.  Some of these changes are so 
fundamental that the assumptions of last year simply don't apply now. 

And we recognized that the BDI has, in one year, become the primary 
distribution of the EMC.  Most of the CD's are sold for the hobby CNC user 
but increasing use is being made to retrofit existing machine tools.  We do 
not see the BDI taking on a life of it's own.  It is and will continue to 
mirror the EMC and the RCSLIB in an easily installable platform specific 
package. 

My recollections of our reactions to this problem in the existing code are to.

1 -- Recognize that there are a wide variety of applications for EMC/RCSLIB 
and that revisions will have to preserve much of the existing capability.  
The code must continue to meet the needs of vehicle and non-cartesian users 
as well as those interested in CNC.  In short we do not want to fork the code 
into different application, platform, task, or distribution specific threads.

2 -- Review the list of platforms that we currently support and remove code 
related to those that are not essential.

3 -- Develop a centralized, uniform way of handling platform specific code 
including ifdef's.   

4 -- Decide on a centralized approach to make.

5 -- Expand the functions of the ini file so that variations in operation of 
the system can be consistently selected and configured at run time.  

6 -- Write consistent developer documentation as these changes are built into 
the code.

Hope this helps further discussion of this essential task.

Ray


on Friday 10 May 2002 06:51, you wrote:
> I realize this may not be everybodies idea of a way to improve EMC, but, a
> number of years ago I was playing around with Forth and read a statement
> Forth was to work on a program and when you get it working - throw it all
> attributed to Charles Moore - its creator - that the best wat to program in
> away and start over - you will have figured out what needs to be done by ty
> then and you will not have to deal with all the work arounds that develop
> in trying to get the idea to work in the first place. I have done that on a
> few small projects I have done and the results were similar to the first
> effort but were smaller and cleaner and easier to maintain.
>
> Perhaps a rework of EMC would be appropriate. A rework with an eye to
> cleaning up the code and making it more maintainable and understandable
> would be a big plus if it is going to be used by the biggest group of
> users. Also, my understanding is, there needs to be some (a lot of) work
> done on the documentation so that the package can be understood. Will EMC
> ever be able to be run at boot? a real CNC needs to boot up to the CNC
> ready forthe E-Stop to be cyled(start button pressed...) and run without
> the
> user/operator needing to do anything. At present Windows (and realtime
> patches) allow this to happen and still maintain security for the network.
>
> Can the code for EMC be reworked so modules for various I/O schemes can be
> easier to install (without a recompile). A move towards maaking EMC more
> like an appliance? Or maybe compling different binaries for each I/O
> scheme - fewer files to download a runtime.
>
> At present I still am not comfortable with working on code in Linx - large
> make files and another language to learn to work with them are to me -
> rather frustrating. The learning curve is very steep and out here in the
> boonies (Southeast Kansas) I am pretty much on my own.
>
> Just a few thoughts.
> Pete Cook