LR>>NR>interface PC's to semiconductor process and measurement tools that
LR>>NR>communicated via the SECS (Semiconductor Equipment Communication
LR>>NR>Standard) protocol.

LR>>   Gads, another protocol I don't know didley-squat about.  Ok, I'll
LR>>   bite, when did this come out - by who?

SEMI -- the Semiconductor Equipment Manufacturer's Institute, if I
remember the acronym correctly.  A loosely organized consortium of
companies that promoted industry concerns and formulated "standards".

LR>>NR> The PC would provide a "friendly" user interface
LR>>NR> that would allow operators to automatically load and start a
LR>>NR> tool (even remotely), while the PC would contain enough
LR>>NR> intelligence to monitor for warnings and serious errors from the
LR>>NR> tools and shut them down if warranted, broadcasting an
LR>>NR> error message to the LAN.

LR>>   What LAN?  How was it used?  Why was it used?

I assume you mean what purpose did the LAN serve, not what particular
LAN was installed.  The LAN served several purposes:  It allowed
operators or engineers to operate or change the configuration of a tool
remotely (clean room environment in which many tools were (un)loaded by
robots) so they didn't have to suit up; it isolated the user interface
portion to a separate PC (the PC's connected to the tools have no
monitor or keyboard), which communicates with the tool PC via the LAN;
process, measurement or error data was communicated via LAN to a
dedicated server which routed the data to one of several mainframe apps
which later manipulated the data to prepare routing reports or
statistical process control charts.

LR>>NR>At the code level, a standard finite state machine controlled the
LR>>NR>various setup, run and monitor states.

LR>>Lost me here Neil. What is a "standard finite state machine"?

A well-worn programmer's device which models the app after a "machine"
which can exist in only one of several "states", such as, e.g.,
initialization, start_run, stop_run, load_chamber,... well, you get the
idea.  It forces you to think about and program for the actual states
that your machine can attain.  Undoubtedly described better in any
number of advanced design texts that you can buy at your local
bookstore.

LR>>   So *how* did the ARTIC resolve this polling problem for the 8 serial
LR>>   devices?  Where do I get literature on this ARTIC - just in case I am
LR>>   given serious consideration for this project - which doesn't seem
LR>>   like a high probability at this point.

It *does* do polling, but it's done by the card's dedicated CPU and
firmware, not by the PC's CPU (so it never runs into the timing
problems that you'd have if the CPU was also trying to run the
operating system and various other applications).  It simply scans the
ARTIC's buffers looking for any new data and, if found, posts an
interrupt back to the controlling program that such-and-such port has
data waiting. It's the responsi- bility of the app to retrieve the data,
flush the appropriate buffer and process the data.

Contact your friendly local IBM rep for info on the ARTIC card (sorry,
don't have an order number); maybe someone else can provide details on
other suppliers of similar cards.

LR>>  Are you still on that same project?

No, not even with the same company.  On to other things.
___
 X SLMR 2.0 X Rap makes me miss Disco...

--- Maximus/2 2.01wb