Operator Interface

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

EMC group.

I'm Ray Henry, I live in the Upper Peninsula of Michigan and I'm new to
this project.   I've serviced machine tools off and on for 20 years now.  I
own three old Hardinge cnc lathes and two moog hydrapoint mills -- none of
them running.  Thus my interest in the NIST software.  I am building
several of  Jon's DC drive boards. (Sounds like an Alcoholics Anonymous
introduction) 

I have concerns about expanding the EMC operator interface and about
expanded I/O and logic. 

I have the emc simulator (May 4) running at home and have had a chance to
work with and study the xemc interface.  I really like it and am convinced
that I could run either a lathe or mill with a screen, keyboard, and mouse
the way that this interface works. I am more concerned about the ability of
the average employee of a job shop to run production using it.  I am also
concerned about chips, dust, and airborne oily residue that are so common
in shops and their effect on keyboards and mice.  For this reason I would
like to consider some kind of expanded operator interface.

Fred convinced me that any kind of interface (except machine e-stop) should
use momentary switches that reach in and touch points in the software
rather than double throw or rotary switches that maintain a contact and
thus a software condition.  Momentary switches allow for access to the
machine from multiple locations.

It seems to me that there are three main approaches that can be taken to
the problem of operator interfaces for a job shop kind of environment. 
 
1.	The first is some kind of virtual interface that uses a touch screen and
a set of windows that have hotspots for the control of all the functions
essential to each kind of machine task.  This would be a lot like xemc but
would have separate, larger button screens for each of the major operator
functions.  Perhaps manual, mdi, auto, tool data, program entry and
editing, and diagnostic screens.  

2.	The second is some kind of visual menu system and real switches along
side the screen that allow the operator to choose those menu items.  You
can see something like what I'm thinking at http://www.ibhsoftec.de/.  This
arrangement would look a lot like the Mazak and Mitsubishi systems that I
am familiar with except the menu would include things like rapid override,
spindle speed, and such.  The menus would depend upon the task much like
the touch screen suggestion above.  It might even be possible to use a
couple of rotary encoders for feedrate and spindle override

3.	The third is some kind of dedicated operator interface panel that
contains all the switches and indicators needed for all machine operations.
 I'm sure that the average machine tool operator today would prefer
dedicated switches with each task sorted to an individual button.  A direct
implementation of this would require a lot of I/O.  Some kind of matrix
switching would reduce the I/O points but would require more programing. 

	Jon suggested to someone a while back that they could pull wires off the
keyboard if they really wanted a separate switch for some function or
other.  There are several boards available in the less than $100.00 range
that break out the individual switch points on a typical keyboard. Some of
these boards multiplex signals this board as well as a regular keyboard.
Such a keyboard encoder would allow for easy access to some functions the
way the emc software works now.  It would have problems with the shift,
control, or alt modified keys. 

	I have done a little bit of experimentation with input through the
keyboard port using a basic stamp2 chip.  The advantage of the embedded
processor is that I can ask it to send any sequence of keyboard codes.
Something like this would allow us to get at the entire set of keystrokes,
even the graphic set, using single pushbuttons.  I've got a rough
incremental handwheel wired all over a table here.  It uses a 100ppr
quadrature encoder, momentary switches to activate it, select axis, and
toggle increments.  The stamp looks at pulse and direction and sends a + or
- keystroke for each cycle as well as the multiple codes required for
activation.  

I'm wondering what you presently do for operator interface and how you feel
about each of these operator interface possibilities.  Or others that
you've thought of.