Re: EMC block diagram posted - corrections wanted

[Ray Henry <rehenry-at-up.net>]

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.

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

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.  

One of the shells that we use is named emcsh.  It includes the essential 
commands for the operation of a gui like tkemc or mini.  This shell includes 
some task, IO, and interpreter NML messages.  A second shell, iosh looks for 
or sends IO type NML messages.  Iosh also has the interesting ability to 
monitor input hardware and exercise output hardware.  

What I find fascinating here is that you can start up and hook in more than 
one of the NML connectors at the same time.  (TNG had a bit of a problem with 
this for a while)  Since NML is broadcast, an E-Stop message originating in 
tkemc is passed through emcsh and will be heard by iosh where it can change 
the setting of a parport or DIO pin.  Or the other way round, a change in pin 
state can be watched by tkio and signal an estop condition in MNL through 
iosh which will be picked up by emcsh, interpreter, and task programs at the 
same time.

I guess the notion of sockets would be a way to respresent this.  Along the 
NML highway all sockets are created equal.  What we plug into a socket 
defines the purpose and the intended targets or transmitters.  This can make 
life interesting if we allow it to.  

For example we could write a single purpose rs232 NML connector (emc232jogsh 
or emcusbjogsh) specifically for jog.  It would look for mode and motion 
messages in NML and would send mode and jog NML messages.  Then we could 
build a simple jog pendant like many machines have using a bit of logic 
processor to read and write serial data.  As long as this pendant's work was 
momentary, it would not necesssarly interfere with or replace other guis or 
HMI's.   

Now stretch the case just a bit and put enough processor in the pendant to 
run enough os to read and write NML out there and you have a smart pendant 
that can control most any process available to this NML highway.  In this 
case we would start a transparent rs232, ethernet, or USB (ug) socket that 
connects the external device to the main PC.  Even here my choice of language 
is faulty because there need be no main PC.  All of the processing work with 
the possible exception of SHMEM and realtime could be out there. 

Ray



On Saturday 05 April 2003 10:46 pm, you wrote:
> I posted a first pass the a block diagram at:
> http://home.att.net/~jekasunich/EMC_Block_Diagram.gif
>
> This is based on info gleaned from the handbook, and from
> a couple of papers I got from the NIST site.
>
> I quickly realized there is no one block diagram, because the
> system works differently depending on how you set it up.
>
> So the drawing includes three versions.  The first is classic
> analog servo.  The Servo To Go card fits this scheme, as
> does Jon's PPMC system.
>
> The second version is what you get when you use Jon's
> Universal Stepper Controler, with feedback from encoders.
>
> The third version is what you get when you use the USC
> with no encoders.
>
> I still need to do diagrams for the parallel port stepper systems.
> I think that steppermod and freqmod are sufficiently different that
> each will want a different diagram, but I need to study mode
> before I can draw either one.
>
> I need more detail on the GUI and I/O portions of the program.
> That stuff isn't my area of expertise, nor is it all that important
> to the discussions we've been having lately, so I didn't put too
> much time into it.  Can anyone add more detail?
>
> Ultimately, I'd like to label each block with the names of the
> source files and functions that implement it.  Being able to
> cross reference chunks of code to their place in the overall
> system should be very helpfull.
>
> Please point out mistakes and suggest improvments.
> Thank you.
>
> John Kasunich