RE: Hardware Abstraction Layer - Rev 0.01

[jmkasunich-at-ra.rockwell.com]

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