Re: regarding future plans for EMC

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

On Tuesday 12 February 2002 11:17 am, Keith Rumley wrote:
<s>
>My understanding at this point is that iosh (tcl prog) does the
> IO in non-realtime. The IO commands go direct (correct me if I'm wrong
> here, Ray) from the Tkemc gui to iosh.

Keith

Yes and no.  Between the gui and the realtime are several logical 
breaking points.  The breakpoint easiest to use is between emcsh running 
tkemc on one machine and the NML socket defined in the ini running with 
the rest of the EMC on another.  This channel is rather easy to set up 
and in fact allows us to run and troubleshoot each others machines over 
the internet. <g>

Tkemc normally uses emcsh rather than iosh.  The differences as I think 
of them are that emcsh deals with the "monitor-mouse-keyboard operator 
interface" and stuff that a human might want to see and do using these PC 
things.  Iosh deals more with IO and pins and switches and makes 
connections between these external things and the running EMC software.  
Both files are ways to get signals from Tcl/Tk programs to the EMC's 
internal NML language and communication environment.

I can illustrate the differences by using an estop example.  Tkemc and 
emcsh might show you a big red button on the monitor that says estop.  
When pressed with a mouse click or touch screen it would issue the 
correct command to place the EMC software in an estop condition.

Tkio and iosh might watch an external red mushroom momentary push button 
connected to a parallel port pin or DIO card and when the contacts opened 
would trigger the same estop condition.  The result is the same but the 
approach is very different. (Nether approach alone produces an acceptable 
estop but that is not a part of my point here.) 

One confusion that we quickly run into between these pairs of files is 
that the specific Tcl/Tk commands used are a bit different for 
each.  Emcio uses a different set of words than does iosh.  Once you get 
to the output of emcsh or iosh, the NML commands are the same. 

You are right on that these parts of the EMC are all normally done in 
nonrealtime as are most of the task and interpreter things.  There are 
some brand new provisions to mix motion signals and io signals into a 
single realtime environment for stuff like the ppmc that Jon is 
developing.  

I'm thinking that these new signal streams will also allow us to write 
our own mixes of signals onto a parport or any other place.  My imagined 
example is a four axis stepper with spindle direction and coolant and no 
hard limit switches but an external estop, feedhold, and cycle start -- 
all defined by variables in the ini.  That's my vision of fat city.

I probably don't understand Fred H's mix of hardware and software very 
well but I think that he is saying that parts of the EMC could be 
rewritten and compiled in such a way that they reside in hardware rather 
than in memory.  That steppermod, freqmod, (or his steptablemod), or for 
that matter stgmod could be committed to an outboard device which would 
handle signals normally sent by other files like minimilltask and do the 
work of connecting to motor amps.    

Ray