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 without issues like
commanding motion from both the motion planner and HAL or
Interp.
failing to clean up after an abort while HAL or Interp are in a
motion command.
Either of these cases could be handled on an individual basis in HAL or
Interp but there are dozens of other possible similar issues. To
effectively produce a safe running system in either of these, the author
will eventually be forced to produce a state based task planner to go
along with the addition of motion with IO or IO with motion.
Think for just a moment about Programmable Logic Controllers. As
initially conceived they were a replacement for relay-relay logic. Then
we quickly discovered that some relays control motion so we added motion
commands. In fact there is a whole class of lathes, some refer to them
as "automatics" that were essentially relay-relay machines. Programming
of endpoints of motion was done using switches. Speed of cut or retract
was handled by pots or hydraulic valves. But try to cut a taper or mill
an arc. These machines whether relay-relay or PLC have the advantage of
working from state. The state of the relay contacts, or cams, or pots.
They did not have the advantage of real coordinated motion.
EMC has the advantage of real coordinated motion. In fact if we look
back to the NIST code coordinated motion dominated and machine state had
either disappeared with the other half of the split backplane or had
been chinked in here and there as needed by specific machines.
Bridgeportio was a perfect example of this. It was specific to one
machine. If you wanted your machine to use bridgeportio you either had
to make the machine conform to an STG card and a specific set of pinouts
or modify the code.
It looks to me like we have coordinated motion pretty well in hand. The
interpreter has grown to handle a lot of of the things that were missing
in the original. We have improved or moved both kinematics and
trajectory planning to the point where they seem to work well. We have
hardware abstraction to the point where there is a clear path from most
any possible set of signals to most any set of hardware. What has not
kept pace is task planning. In fact I've seen determined effort to move
task away or let it die.
I'm sitting here looking at my, now empty, NIST coffee cup. It shows a
three by three matrix based on some papers developed by folk there that
describes their early vision for intelligent systems. The three rows
represent levels of command. Global, local, RT. The three columns read
Sense, Model, Act. There is a set of arrows that connect these boxes is
specific ways.
What we are missing in both of these proposals is modeling of behavior
based upon state as well as command. 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
Hope this helps
Rayh
On Mon, 2007-01-29 at 17:36 -0500, Kenneth Lerman wrote:
> I would use a completely different approach; it wouldn't be HAL based.
>
> I would provide signals that could be output from gcode to HAL and those
> that could be read by gcode from HAL. They would be used to sense
> microswitches, command relays, etc. Reading a switch would be done like
> probing already is -- it would be done synchronously. I would also add (it
> might already be there) the ability to access the current state of the
> system -- current X, current Y, feed rate, etc, by storing them in special
> parameters.
>
> Then I would do all of the commanding and control by writing gcode. That
> code could save the current state, do the appropriate motions, restore the
> current state, and continue.
>
> If we were worried about the user "accidently" messing with this special
> gcode, we could provide the ability to allow only gcode subroutines that
> were loaded at startup to have the ability to access this I/O.
>
> Ken
>
> [EMAIL PROTECTED]
> Mark Kenny Products Company, LLC
> 55 Main Street Voice: (203)426-7166
> Newtown, CT 06470 Fax: (203)426-9138
> http://www.MarkKenny.com
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jeff
> Epler
> Sent: Monday, January 29, 2007 4:40 PM
> To: emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] Proposal for HAL-based motion control
>
>
> Is this the way we should approach sequences of motions for toolchanging
> and the like? Comments, please.
>
>
> HAL-BASED MOTION CONTROL
> ========================
> Often, it's desirable to command a sequence of motions outside of g-code.
> For instance, a number of movements may be required during a tool
> change. The modifications proposed below allow for this kind of
> control, and make 'halstreamer' an example component capable of
> exercising this control. (It is anticipated that special-purpose
> HAL components, rather than 'halstreamer', would command the tool change
> motion in actual systems. It is up to an integrator to write an
> appropriate component)
>
> Motions in the external-position mode are performed in "exact stop" mode
> (suitable for tool-change motions but probably not for machining), and
> respect the machine's velocity and acceleration limits. It is hoped
> that the implementation can re-use the so-called "free planner" which is
> used in jogging.
>
>
> NEW PINS ON THE MOTION CONTROLLER
> =================================
> motion.external-position-command BIT IN
> When TRUE, the machine's position is controlled by the
> external-position-<AXIS> pins. On the transition from TRUE
> to FALSE, the machine returns at "traverse" speed to the
> position it was in before this pin was asserted.
>
> motion.external-position-<AXIS> FLOAT IN
> (<AXIS> is one of X, Y, Z, A, B or C)
> Drive with the requested position in machine coordinates
>
> motion.position-<AXIS> FLOAT OUT
> Driven with the current commanded position of the axis
>
> motion.external-position-velocity FLOAT IN
> Drive with the requested velocity.
>
> motion.external-position-control BIT I/O
> When the external position is reached, motion sets this pin TRUE.
>
>
> CHANGES TO HALSTREAMER
> ======================
> If the first letter of the streamer configuration string (cfg=) is '+',
> then the new pin is created on a 'streamer' instance. Otherwise, the
> 'streamer' outputs one sample per invocation, as it does now.
>
> streamer.<N>.next-sample BIT I/O
> When this pin is TRUE, streamer outputs the next sample and sets
> this
> pin FALSE
>
>
> COMMANDING MOVEMENTS WITH HALSTREAMER
> =====================================
> The following illustrate how halstreamer can make a series of
> coordinated movements, drawing a 2-unit square at 1 unit above the
> machine origin at 5 units per minute. To begin the sequence, drive the
> signal 'external-control' TRUE (for instance, with a 'halcmd setp').
>
> # Additional HAL configuration
> loadrt streamer depth=4 cfg=+bffff
> net external-command motion.external-position-command streamer.0.pin.0
> net external-x motion.external-position-x streamer.0.pin.1
> net external-y motion.external-position-y streamer.0.pin.2
> net external-z motion.external-position-z streamer.0.pin.3
> net external-a motion.external-position-a motion.position-a
> net external-b motion.external-position-b motion.position-b
> net external-c motion.external-position-c motion.position-c
> net external-vel motion.external-position-velocity streamer.0.pin.4
> net external-control motion.external-position-control
> streamer.0.next-sample
>
> # Sampler input file
> # X Y Z vel (unit/sec)
> 1 -1.0 -1.0 1.1 10000.0
> 1 -1.0 1.0 1.0 0.08333
> 1 1.0 1.0 1.0 0.08333
> 1 1.0 -1.0 1.0 0.08333
> 1 -1.0 -1.0 1.0 0.08333
> 1 -1.0 -1.0 1.1 10000.0
> 0 0.0 0.0 0.0 0.0
>
>
> OPEN QUESTIONS
> ==============
> Q. Should feed override, adaptive feed, or feed-hold apply to these
> motions?
>
> -------------------------------------------------------------------------
> 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-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> -------------------------------------------------------------------------
> 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-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
-------------------------------------------------------------------------
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-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
