RE: Hardware Abstraction Layer - Rev 0.01

["Craig Edwards" <cedwards-at-ceinetworks.com>]

?"Judging from the deafening silence after I posted my proposal, I don't
think much is going to happen soon.  I personally have a steep learning
curve to climb before I'm ready to write
>code.  I am very comfortable with writing the actual real-time code,
but the mechanics of makefiles, platforms, etc., are going to take some
getting used to."

Yea.. Given the enthusiasm of the discussions at NAMES... I'm kinda
surprised as well.  But give me a week or two and I might be able to
help, I'm trying to recruit an experienced Linux person.  Also I'm sure
that Paul C. will help..... Once he lands home again...:)

BTW, since no one else commented....THANKs for taking it this far,
you've really put a lot of your thought and experience into this.

Craig  

-----Original Message-----
From: emc-at-nist.gov [emc-at-nist.gov] On Behalf Of
jmkasunich-at-ra.rockwell.com
Sent: Wednesday, May 07, 2003 3:33 PM
To: Multiple recipients of list
Subject: RE: Hardware Abstraction Layer - Rev 0.01





Craig Edwards wrote:

> My vote is to keep this topic here for now, till we hear
> from Fred or Will that they would like to formally move
> this list to sourceforge.

OK by me.

> With regard to your HAL proposal, I strongly favor the implementation 
> of a true hardware abstraction layer, for all the reasons you 
> outlined.

> give some thought as to how the work might be partitioned
> up, as this does seem like an extensive upgrade / rewrite
> of EMC.

It is a big step.  At the meeting there was talk of "stable" vs.
"development" versions.  Several of the projects we discussed (including
the HAL) are big enough that we probably should do something along those
lines.  That way the stable branch can continue to be used and receive
minor bugfixes while the new branch is evolving.

Judging from the deafening silence after I posted my proposal, I don't
think much is going to happen soon.  I personally have a steep learning
curve to climb before I'm ready to write code.  I am very comfortable
with writing the actual real-time code, but the mechanics of makefiles,
platforms, etc., are going to take some getting used to.

> One addition request / comment / question.  In the case
> of an implementation where the servo PID loop is closed
> with external hardware, could positional data from the trajectory 
> planner just be "passed through" the servo loop routine and output via

> the HAL with minimal changes to the architecture?

At first I thought it wouldn't be too bad, a servo loop is
a reasonably well defined "component" and maybe it can be pulled out.
In reality, the interpolator, the servo loop, the home/limit logic, and
the manual/auto mode logic are all part of emcmot and they all interact
to a lesser or greater extent.  It may still be possible to pull the
pieces apart and define clean interfaces between them, but it will take
a better brain than mine to do it.

In general, you are on the right track.  The only way folks other than
Fred and Will can make significant contributions to the project is if
they can focus on a section of code with clean, side-effect free
interfaces to the rest.  NML makes that possible on the GUI side, which
is why we have so many GUI choices, and why the GUI keeps getting
better. I'm focused on the other end with the HAL.

> I guess what I'm really suggesting is that we include a feature in 
> this version whereby this is made feasible
> and efficient.   Perhaps a var in the init file could be
> defined that would "enable" position or velocity mode?

I expect that what you want might require a replacement
version of the "emcmot" module.  That's not so bad, since
both versions could be compiled and you decide which one
to use at run time (possibly based on an ini file option).
But again, it requires a well defined interface.  It might
also be possible to do it using tuning parameters only.
If you set P, I, and D gains to 0, FF0 gain to 1.0, and
all the other FF gains to zero, I _think_ the output of
the "servo loop" will be exactly equal to it's input.
But it would take carefull examination of the code to
verify that.  I know that "output scale" would be a complication that
would have to be dealt with, and I'm sure there are others.  The problem
with disabling the servo loop using tuning parameters is that the loop
is still there, consuming CPU cycles.  A seperate module with the
unneeded code stripped out would be faster.

John Kasunich