Re: [Emc-developers] Proposal for HAL-based motion control

[Ray H. <re...@up...>]

Thanks for the quick response, John.  "Flow control" is a great term for
what our task planner ought to do for us.  

I have seen and can easily understand how each developer, when faced
with an issue, in this case tool change, will think first about the
portion of code they are most familiar with while avoiding those least
familiar.  Task is certainly least familiar to most all of us.

Years ago I was talking about the creation of a new HMI interface
library and the thought came up that we could fix our "unit" problem
there.  The units used in computation is one of those things that was
not handled well by task then.  At that time there were work arounds for
poor unit handling in nearly every other process.  Rather than adding
another patch in an outboard library, we did nothing.

I like your thought that we need to separate task into process and
system specific configuration.  This reminds me of the layers or rows of
activities on my NIST coffee cup.  That lowest row is task as configured
by the integrator while the layer above is a local instance of flow
control relevant to that box and it's place in the machine.

It is also clear to me that the article referenced goes somewhat beyond
or along side the task of running machine tools.  The first thought that
hit me when I was thinking of vehicular movement was a combination of
terrain difficulty and perceived threat.  But even these can be, perhaps
should be considered while we are thinking of soft limits, chuck
barriers, or space reserved for work holding.  The idea of a "do not go
there" vs a "walk softly here" are valuable machine tool configuration
options.

There is also the issue of legacy.  The argument, "The old tasker did it
this way," ought to inform us about part of what needs to be done, not
how it ought to be done.  I see no reason why a revised tasker should
handle things like "abort" or "tool change" the same way the old one
did.  If direct communication with running HAL modules is more efficient
and still as effective/safe then we ought to revise the communication
paths to reflect our advances in other parts of the system.  If
preconditions and post conditions to specific commands or exceptions are
handled more efficiently in task than they are in the interpreter then
we ought to move them.

It is also clear that a commitment to a revised or new task planner will
involve the use of programming languages some of us are less familiar
with and less adapt at using/reading.  As you already know most all
programming languages are alien to me.

Rayh


On Tue, 2007-01-30 at 19:35 +0000, jmk...@at... wrote:
> Ray Henry <re...@up...> wrote:
>  
> > And I'd interpose a third way -- task. Both of the above approaches 
> > using the HAL and the Interpreter have a good deal of merit within the 
> > context of each system. What is missing from each is a system wide way 
> > of describing the state of the machine so that effective coordination 
> > between IO, motion, and command can be handled
> 
> You may well be correct, that task is the "right" place to do such things.
> I think one of the main reasons we find ourselves looking to either g-code
> or HAL is that task (as currently implemented) is not flexible/configurable,
> while g-code and HAL are.  Task is written in C++, and if you want to
> change it, you fire up your editor and modify the source, then recompile.
> And you hope you didn't break something when you made your changes.
> 
> On the other hand, both g-code and hal are easier to change.  Neither one
> is a general purpose programming language, although g-code is probably
> closer than HAL.  Both lack such basic features as named variables, 
> variable scope, etc.  HAL lacks even rudimantary flow control, while
> g-code's abilities in that area are limited.  What they do give you is
> the ability to make high level things happen with one or two lines of
> "code", and well defined side effects.  In g-code, you can simply write
> G1 to generates a coordinated move, with little concern about anything
> happening beyond the move.
> 
> However, someone who starts modifying task to make it do custom things
> needs an enormous amount of knowledge about the existing system.  Other-
> wise, there is no way he can anticipage and deal with the various side
> effects of his actions.
> 
> Excuse my rambling, but let me put it another way.  G-code splits the
> task of making a part into two chunks.  The g-code itself is contains
> the part specific knowledge, and the interpreter contains the general
> knowledge (the definition of the language).  Likewise, a HAL config file
> contains system specific knowledge, while the HAL itself contains the
> general knowledge (definition of the language and the behavior of the
> individual components).
> 
> Task doesn't have this split between application specific knowledge and
> general knowledge.  The application specific stuff is buried in the code,
> right next to more generic stuff.
> 
> Perhaps we need to look closely at task, with the idea of separating
> out the application specific stuff.  We need a "language" that can
> tell task what machine specific things it needs to do, in the same way
> that g-code tells the interp what to do, and .hal files tell the HAL
> what to do.
> 
> > Let me suggest that you read the following abstract and if you find
> > things that disturb your current thinking about the EMC software, 
> > download and read the document. While it deals in more complex 
> > IO/Motion systems that we do, the principles are the same. 
> > 
> > Barbera, et-al say, 
> > 
> > "The Real-time Control System (RCS) Methodology has evolved over a 
> > number of years as a technique to capture task knowledge and organize it 
> > in a framework conducive to implementation in computer control systems. 
> > The fundamental premise of this methodology is that the present state of 
> > the task activities sets the context that identifies the requirements 
> > for all of the support processing. In particular, the task context at 
> > any time determines what is to be sensed in the world, what world model 
> > states are to be evaluated, which situations are to be analyzed, what 
> > plans should be invoked, and which behavior generation knowledge is to 
> > be accessed. This results in a methodology that concentrates first and 
> > foremost on the task definition. 
> > 
> > http://www.isd.mel.nist.gov/documents/barbera/How_task_analysis.pdf 
> 
> Interesting document.  I've only skimmed it so far, but good stuff.
> It basically outlines a process that is used to break up complex tasks
> like driving a vehicle (or running a machine tool) into smaller and
> smaller tasks which can eventually be implemented in software.  The
> main problem that I see is that it assume a team of developers is 
> going to go through the process from scratch for every new top-level
> task.  That's fine when you are NIST and your individual projects are
> very challenging, such that you expect to spend months or years working
> on each one.  You can go through the process, and embed what you from
> it directly in the code.
> 
> But when you are a machine builder, you can't afford to go through
> the entire process from scratch.  You want to be able to use as much of
> the existing knowledge as you can.  Thzt means the knowledge can't be
> buried in the code.  It needs to be out in the open, where you can 
> read it, and modify the parts that you need to change for your specific
> machine.
> 
> EMC's ini file has always been intimidating to new users, because
> it is an attempt to do exactly that.  It puts a _lot_ of information
> out there where you can change it, even if 95% of users are only gonna
> change 5% of the items.  HAL is the same way.  But even that isn't
> enough = there is still a lot of hard-coded behavior in task and 
> elsewhere.
> 
> In general, you can take one of two paths - you can keep the configs
> simple by hard-coding the vast majority of behaviors, or you can stay
> flexible by using configuration data to define almost everything.  You
> can't do both.  If we want to support a wide variety of machines, we
> need to get the behavior definitions out of task and into some sort
> of configuration.  (The behaviors might still be implemented by task,
> but they would be based on the config data, not hard-coded.)
> 
> An example of this is the tool-change stuff.  EMC1 (and I believe 
> EMC2) has a "tool change position" in the ini file.  That is the place
> where the machine goes when its time to change tools.  Works great
> for tradtiional toolchangers, because that is what the developers
> had in mind when they hard-coded that behavior.  But there are tool
> changers that store the tools in slots on the table, such that the
> machine needs to move to a certain slot to get the tool.  The current
> task simply can't deal with that, because it doesn't fit the hard-
> coded expectations.
> 
> The problem with getting all the hard-coded stuff out into the
> config files is that the 95% of people who only need to change 5%
> of the configuration are gonna be intimidaged by it.  I really 
> don't know the answer to that problem.
> 
> I think this is a usefull discussion.  I'm glad Jeff started it,
> and I look foward to seeing where it goes.
> 
> Regards,
> 
> John Kasunich
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>