regarding future plans for EMC

[Fred Herenius <fred-at-twonky.xs4all.nl>]

Greetings list,

lately there have been quite a few interesting posts on the subject of
the future development of EMC, and this sparked my interest enough to
stop lurking and start posting. 

Points of discussion:
- rewrite/cleanup of code
- user/developer help with getting started
- planned features
- homebrew hardware
- commercial hardware
- reactions to miscellaneous snippets
- a few short questions


Rewrite/cleanup of code:
To get EMC working with my hardware (DIY) I had to make several changes
to some modules. And let's just say that in the parts that I checked (mainly
EMCMOT and EMCIO related) the availability of room for improvement was
prodigious. And hold it on the "Now then, please submit a patch and we're
all happy." remarks please ;) Well, at least for now.
Someone who would like to contribute code would need to be able to find his
way through the source-tree. A time-honoured method of getting familiar with
the structure of a source-tree is spending waaaay too much time reading
source. As much fun as that can be, I'd rather read a concise document
telling me where to find what. Is there any such document?


User/developer help with getting started:
I wanted to start about the lack of documentation, especially for people new
to this entire linux/rtlinux/emc thingy. But then again, I recall that there
was being worked on, so before writing on I shall check the current state...
... Checking out documents from cvs ...
Mmmh, /documents/temp_html/part3/sourcefiles.html seems to be the description
of the source-tree I was looking for. Or at least a good starting point.
Been browsing the documentation for a bit, and I must say I'm impressed with
the progress :) What I'm still missing somewhat is a list of supported
hardware. The only thing listed is "Servo to go", but somehow I don't
believe this is the only piece of hardware being used out there. Now I realize
that you can find out enough information on the net, but I think you could get
more people to use EMC if you have a more complete list of supported hardware.
The rest I'll save for the commercial/homebrew hardware discussion bit.


Planned features:
Pete Cook> My personal belief is that EMC could still be classified as beta,
Pete Cook> with ideas still in development along with the development of those
Pete Cook> ideas.
If this is indeed the case, is there any planned date for a feature-freeze?
If a lot of people feel that there still are way to much features to be added
to do a freeze, then what are these features? Is the current set of features
insufficient to do a certain type of work, and why? How many people are
actually going to use exotic feature X, and is it worth waiting for? I am
fully aware of how hard it can be to stop adding features when those nasty
ideas just keep on bubbling, but sometimes you just have to stop adding or you
never get something finished.
Perhaps an idea would be to make two separate source trees. One will be the
current source-tree as it is, and you can continue adding features at will,
and generally experiment as you like.
For the second one you agree upon a limited set of features most commonly
used, and start building a clean tree only implementing those features. You can
do this by taking the current tree, throw out unwanted stuff, clean this bit,
rewrite that bit, until you are satisfied that it is clean and operational.
Or you could do a complete rewrite. The choice would depend upon a lot of
things, among those:
- current state of code
- how many people are willing to work on tree 1 vs tree 2
- are there even enough developers as it is?
- <shadow>What do _you_ want?</shadow>

An option worth considering is to improve it module by module. I've got
the impression that EMCMOT and EMCIO are the modules that are in the least
desirable state.

- assume the interfacing between modules is OK (gotta check that)
- assume EMCIO is in a sorry state, and a rewrite is needed
- assume EMCIO is the smallest module
- do a complete rewrite of EMCIO as a sort of pilot, to show it can be done
  and much better code is the result. Also it can be used as a sortof style
  template to be used for the other modules.

As you can see, a lot of ifs I cannot resolve without either spending
more time in the code myself, or input from others. For now, I'd prefer
the latter *hint* *hint*


Homebrew hardware:
Another reason for going the above route of doing it module-wise is as
a proof that the modularity is actually working. And if the modularity
is actually working you can start thinking about moving modules (in whole
or in part) to a platform different than your main pc/alpha/whatever.

For example, you could make a board to control the rotational speed
of your favorite spindle. Instead of using the PC to generate the pulses,
you could use a lowly microcontroller to do that for you, and to accept
high-level commands from the PC through a (serial) bus of your
preferred flavour. At home I use I2C for this, but in an industrial
environment you could use something else.

If that concept works for EMCIO, then why not for EMCMOT?
The thing is, I'm planning a CNC conversion of a lathe in the future, and will
build a new controller for it. Since I intend to do adaptive filtering I will
basically throw out the avr of my current setup, and plug in a DSP. A good
candidate is the TI TMS320LF2407 since it has nearly all the features I am
looking for, and is available for about $16 in single units. Among the planned
features for this controller are microstepping and torque-control, so the 
16 channel ADC in the DSP is quite a handy feature. Also included are PWM and
event handlers, etc, etc, the works for motion control. If interested, check:
http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TMS320LF2407

If feasible, the plan is to move the EMCMOT module (in part or in whole, not
sure yet) to the DSP.

And on the subject of homebrew hardware, how about trying to get a
repository with plans for homebrew controllers. Schematics for those who
like to wirewrap/breadboard/etc. Postscript or other plot-files for those
who like to etch their own. I know there are a plenty of schematics on the
net, but for the beginning EMC enthusiast it might be much easier if there is
a clearly defined list of homebrew designs to choose from that are know to
work with EMC, complete with description on how to get it up and running.

Also, I'd be interested in hearing from other people that intend to use DSPs
for control, or adaptive filtering solutions on the pc-side in EMCMOT. Now
what was that again I said earlier about stopping adding features? ;->


Commercial hardware:
Since CNC is just a hobby interest for me, I have no real idea of all the
commercial controllers out there. About the only thing I know about them is
that you pay way too much money for what you get. If I sometimes look at
this or that controller and make an estimate of what it will cost me to get
it done myself (labour exclusive), factors of 10++ seem to be the norm.
But there are those that might consider using EMC in a professional setting
with professional controllers if there was more clear-cut support for them.
And "Oh it will work, you just have to tweak this and that piece in thingy.c
and you're all set" is probably not what they want to hear.


Reactions to miscellaneous snippets:
Subject: Re: RESOLVED: EMC is poorly designed and implemented.
From: "Pete Cook" <kf2qd-at-terraworld.net>
> Is there any one programmer who can devote anything more than hobby time to
> work on EMC? Is there any involvement by a corporately sponsorred
> programmer? Is there anyone at NIST or elsewhere who is putting 10 hours or
> more a week into improving EMC?
Good question. I'm considering getting involved but I need a bit more
information as to what the available resources currently are.

> Might there be more involvement if the OS were something other than Linux? I
> am thinking more of a DOS or FreeDos environment.
Install Yoda style "DOS -> anger -> hate -> suffering" quote here.
Why would you want to do that? To trade the linux learning curve for the DOS
learning curve? I admit that the dos curve could (not even sure about that) be
less steep, but why the hell would you walk any curve (steep or not) to reach
a destination you don't want to reach. Going to DOS may however be a perfect
way to loose potential developers. Let us not think upon that anymore...
OK, let's try a more productive approach. Where do you feel is the biggest
hurdle for people to get involved?
Is it getting a distro up and running? Plenty of HOWTOs of the different
distros on the net.
Getting the programming environment up and running? Too easy with all those
package-managers around. apt-get install rules :)
If you already got it working from source, then you already have the
compilation part taken care of. About the only thing you need then is the
editor of your choice and some debugging tools (all hail the mighty printf).
Now a thing that may be tricky at first is getting up to speed with X
development, but nowadays life is so much easier with all those toolkits to
choose from. Could go on here, but chances are you're referring to something
else.
So again, what do people think would be the biggest hurdle for others to get
involved and start developing? For me personally the biggest hurdle would be
to get a good overview of the sourcetree.

> Another approach would to move EMC off the main CPU and onto a PCI or ISA
> type card - yes this would require the design of special hardware, but it
> would make the OS of less importance. 
As said, I'm all for that. Well, at least for EMCMOT and EMCIO. The GUI and
EMCTASK are just fine on the PC. Oh one other thing, I wouldn't make a
PCI or ISA card. I'd just make a standalone board and let it accept high-level
commands from EMCTASK (on the PC) over a serial link. As a bonus you have less
chance of blowing up your slots while developing the boards ;-)

Subject: Re: Steppers getting signal, but not turning
From: "Scott Holmes" <norgasm-at-hotmail.com>
> What controller are you using?  are the pins mapped correctly to the EMC
> pinout?  Does the controller have a DB-25 on it that you're plugging in to?
> If so you may have to change around some signals to match EMC.  The easiest
> way is to just make up a custom DB-25 cable that shuffles the signals around
> as required.
Another thing I ran into. The easiest way for someone not willing to go into
the source is indeed to change the cabling. IMO it is possible to make it so
that you can describe in an ini-file which pins are which. Some time ago
I was going to do just that, but I wasn't exactly encouraged by the state
of the code, so I just decided on a quick fix.
If there were to be made some changes I'd propose something like this:
(BTW, this is referring only to steppers, haven't looked into the rest)
- kick out variations on a theme (stepmod, freqmod), and make one generic
  module for controlling stepper motors. Should not be a problem since there
  was some talk on one of those getting ditched anyway when going to the
  latest and greatest kernel. Perhaps a good excuse for a rewrite?

One way of going about it:
- one steppermod, so one source, and none of that profligate ifdeffing
- table-driven (faster and cleaner)
- fill tables on startup, based on contents of ini-file describing wiring
You get two subtypes (phase-drive and clock+direction) with one module.
IMO the small differences between the two do not warrant seperate sources.
And certainly not the ifdeffing I encountered.


A few short questions:
- Anyone know a cheap source of good encoders in Europe? The Netherlands
  to be more specific. I know, I know, cheap vs good...
- Just thought I'd ask, anyone else on this list into hobbying with
  FPGAs, CPLDs, DSPs, that sort of thing?
- Are you still reading this?


nuf said,
Fred Herenius