Re: EMC block diagram posted - corrections wanted

[John Kasunich <jmkasunich-at-worldnet.att.net>]

At 12:28 PM 4/6/03 -0400, Ray Henry wrote:

>Hi John
>
>Nice job on this.  Sorts out several relationships.  Two quick things come to
>mind, NML and a bit of an expansion to the gui stuff.  This is a quick reply
>and I'll spend more time on it a little later.
>
>You should treat my NML discussion here as crippled at best and faulty at
>worst.  It is only my thinking.  Will, Fred, and several others should jump
>in here to affirm the correct and fix the faulty. IMO NML is a kind of data
>highway.  It is pretty much the connector between all of the nonrealtime
>processes.
>
>Where you have logical arrows from the gui to IO, Interpreter, and Manual
>(Task) these all travel through the single NML pipeline.  If we model this
>with wires or traces, these are bi directional electrical packets traveling a
>single trace.  They are recognized or ignored by the various processes along
>the trace by the specific NML abilities and lexicon written into each
>specific process.
>
>While you might think of this a bit like a major freeway, the difference is
>that all packets arrive at all off ramps and packets sent by any process
>arrive at all other processes.  It's more like a multipoint single channel
>broadcasting system.  Each node hears every other node.
>
>Now I don't know quite how to represent this in your diagram.  The thought
>that comes to mind is a multiconductor shielded cable but it's really a
>single coax.  As your arrows indicate, one intent of the gui is to
>communicate certain messages to the interpreter.  It is also the intent of
>the interpreter to communicate with the gui.  Neither is a descrete wire or
>channel that is not also available to task or IO or any other process that
>happens to be listening or speaking its specific part of the NML language.

I'm more interested in representing the flow of messages, rather than the
cable they travel on.  For instance, a jog command will be sent from
some user interface object, and it will be acted on by the motion routines.
So an arrow from GUI to MOT labeled "jog" is accurate, even if the actual
message flows on a "major freeway" with other messages going to other
places.  It does get more complex when more than on module acts on
or originates a given type of message.  We'll probably wind up with a lot
of arrows :-(

The documentation doesn't have to be entirely graphic - the diagrams help
break things up into areas, but text lists of the types of messages and what
each one does would be very useful too.

>NML, as we know it now, only works on the nonrealtime side of the processes.
>Shared memory is a fixed boundary layer between realtime and NML

So there is one chunk of non-realtime code that recieves NML messages and
writes them to shared memory, and builds NML messages from data in the
shared memory?  Then the real-time code simply accesses the shared
memory?  I think I follow that - I'll draw it as an interface layer between the
realtime and non-realtime modules.

>The gui end of things.  The older guis like xemc, yemc, keystick, and
>emcpanel all have their NML connectors built in.  The Tcl/Tk guis have a
>modified shell (wish) that they run in/under.  This modified wish shell has
>the NML connectors built into it.

<snip lots more information>

More info than I can process right now, but saved for when I have more time.

Thanks Ray,

John Kasunich