Re: regarding future plans for EMC

["Wayne C. Gramlich" <Wayne-at-Gramlich.Net>]

Matt Shaver wrote:
> 
> Fred Herenius wrote:
> 
> > But I'll ask
> > again, are there any active plans concerning cleaning etc of code?
> 
> I guess it depends upon the meaning of "active", "plans", and "cleaning"
> ;) . Let me address these in reverse order:
> 
> "cleaning"
> There are too many #ifdefs. Part of the reason is that the EMC will
> (might?) compile and run on several different platforms (PC Linux, SGI,
> Windows, Alpha, etc.) and for Linux there are several versions of
> rtlinux supported as well as RTAI. If we could narrow the these choices
> down to one, a lot of the #ifdefs would go away. The problem is that,
> although 99.999% of all EMC systems are PC/rtlinux systems, there are (I
> assume) SOME users of the other platforms. Should they be abandoned?
> Should there be a streamlined EMClite (I really hate that name, don't
> use it...)? Another possible "have your cake and eat it too" solution
> would be to move as many of the conditional statements into the build
> system as possible using autoconf and automake. This leads me to...
> 
> "plans"
> Let's see, so far I've talked to Fred & Will at NISTand Ray Henry about
> switching to autoconf and automake. I also started reading _The Goat
> Book_ (http://sources.redhat.com/autobook/). I am in over my head, but
> flailing madly to stay afloat...
> 
> "active"
> This is the hardest one. For myself, before I could even begin to make
> any changes, I'd have to really understand the existing code. As I am
> only a beginning C programmer, that's a lot to swallow... Perhaps the
> thing to do first is to write better (more?) documentation.
> 
> Matt

All:

I've been lurking on this list for about 3 weeks now and this
is my first post to this list.  By way of introduction, I am
a CNC `wanna be'.  I am currently designing a 4-axis motion
control board for stepper motors using L298's and a future
`black box' that I call a buffer board.  These projects are
incomplete, but people are welcome to see what I have done
so far at:

  http://web.gramlich.net/projects/cnc/controller/index.html

With regards to the future plans for EMC (see quoted message above),
I thought I would throw in my relatively uninformed opinion and
see if anybody thinks it will fly...

I suspect that EMC can be partitioned into two pieces --
a front end and a back end:

 - The front end takes the G-codes in and emits computes
   the desired times and positions for the machine.  These
   are represented as N tuples, where the first value is
   the time in some convenient representation, and the
   remaining values are the values needed for each axis.
   For a three axis machine, the output of the first piece
   would be a stream of 4-tuples of the form (t, x, y, z).
   Note that the front end needs no knowledge of RTLinux
   or the like and can loose all of the RTLinux #ifdefs.
   This partioning has the added benifit of allowing the
   front end code to be more easily ported to other platforms.

 - The back end is the real-time piece that takes the N-tuples
   and causes the parallel port lines to wiggle the right
   way at the right times.  This can be done using RTLinux,
   RTAI, or using some `black box' protocol.  This code
  would need all of the RTLinux #ifdefs.  If the back end
   driver code got too ugly, it could be split into separately
   maintained drivers (e.g, an RTLinux driver, an RTAI driver,
   etc.)  Lastly, for those corporations that want to develop
   some super secret black box technology, they could invest
   their effort into building a back end driver for there
   platform, but continue to use the EMC front-end.

Anyhow, those are my basic thoughts on the subject.  If I'm
totally off base, I'd appreciate it if somebody would correct
me and appropriately redirect me.

Thanks,

-Wayne