Industry News, Trends and Technology, and Standards Updates

In 1977, the classic movie "Close Encounters of the Third Kind" was released.  Towards the end of the movie, there is a dramatic "conversation" between the space aliens and the humans. One of the scientists makes the statement, "I hope someone is taking all this down."

What they really wanted was message logging!

Just like software logging is important for troubleshooting an application, logging the detailed message traffic between a factory host and the manufacturing equipment is just as important for troubleshooting.

For example, a host sends a command, and the equipment behaves based upon the message, but something does not work as expected.  It would be very helpful to see the message that was sent and the reply from the equipment, in conjunction with any other logs from the equipment to determine where the problem is located.

The format used to display/represent the logged messages is also very important. The latest industry standard for SECS message formatting is SEMI E173, the Specification for XML SECS-II Message Notation (SMN).

Here is an example:

<?xml version="1.0" encoding="utf-8"?>
<SECSMessageScenario xmlns="urn:semi-org:xsd.SMN">
                <Comment time="2018-02-05T18:19:20.365Z">State Change NotConnected</Comment>
                <Comment time="2018-02-05T18:19:20.400Z">State Change NotSelected</Comment>
                <HSMSMessage time="2018-02-05T18:19:20.394Z" sType="Select.req" direction="H to E" txid="1">
                                <Header>FFFF0000000100000001</Header>
                </HSMSMessage>
                <HSMSMessage time="2018-02-05T18:19:20.417Z" sType="Select.rsp" direction="E to H" txid="1">
                                <Header>FFFF0000000200000001</Header>
                                <Description>Communication Established</Description>
                </HSMSMessage>

Here is an S5,F5 example:

<SECSMessage s="5" f="5" direction="H to E" replyBit="true" txid="7" time="2018-02-05T18:19:20.507Z">
    <SECSData>
        <UI4 />
    </SECSData>
</SECSMessage>
<SECSMessage s="5" f="6" direction="E to H" replyBit="false" txid="7" time="2018-02-05T18:19:20.507Z">
    <SECSData>
        <LST>
            <LST>
                <BIN>0</BIN>
                <UI4>1</UI4>
                <ASC>Alarm 1 Text</ASC>
            </LST>
        </LST>
    </SECSData>
</SECSMessage> 

The SMN format is ideally suited for:

• Capturing the HSMS header information in a clear way
• Logging messages in an exact, binary format
• Reading the logs using software
• Creating a host or equipment emulator, since it is easy to read the logging from a software application and play it back.
• Extracting data from the SMN logs

The logs can be captured by the Equipment, Host, or even a "network sniffer" like Cimetrix's CIMSniffer utility.

Cimetrix’s Logviewer utility supports SMN logs as well:

With these standards and tools available, there's no reason to be like the scientist in Close Encounters, hoping that the messages were being logged.  Turn on logging!

Cimetrix's CIMConnect, HostConnect and SECSConnect all provide message logging in the SMN format.

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper with an introduction to SECS/GEM, Click below:

You have designed the ultimate process that will revolutionize the semiconductor industry.  The parts have been collected, the process module assembled.   But now you need the software to make all the components work together.

As described in a recent CIMControlFramework (CCF) blog post around designing recipes, the recipe is the secret sauce for your process.  The recipe is used to direct the hardware to perform the process; How much time in a step, temperature, gas flow, pressure, etc.

The recipe provides directions to the process module on how to perform the processing.  How and when to enable/disable hardware components.  What setpoints to be set for components.  How much time to spend on any given step.  The process module (PM) software that you develop will take the recipe that you have defined and perform the operations using that recipe. CCF stays out of your way to allow to create your secret sauce.  

CCF makes integrating your process module easy.  CCF provides a simple process module interface that allows CCF to know when to prepare for processing, prepare for transfer, and process using the supplied recipe.

 Your process module hardware may be made up of any number and types hardware components, E.g.  Mass Flow Controller(s), valves, chuck, etc. that will be used to process the recipe. Since CCF does not use proprietary interfaces and does use C# and Visual Studio, creating interfaces to your hardware is much easier and left to you to design and develop these drivers. CCF makes it easy to connect to your hardware, whether it is via a PLC or talking directly to the hardware. 

CCF makes it incredibly simple to report data to a UI, a GEM host and even an EDA client.  Declare your status variable, update, and publish.  The data is reported to all three for you automatically!!

CCF takes the stress out of the necessary evil of moving material through the equipment to get it to your process module. It provides an interface for interacting with your process module allowing you to spend your time where it matters most - creating your secret sauce to help make you successful!

To learn more about CCF, visit the CIMControlFramework page on our website!

In 1976, Blue Oyster Cult released their hit song, “Don’t Fear the Reaper”.  In 2000, Saturday Night Live produced a fictitious, but humorous skit around the production of the “Don’t Fear the Reaper” called, “More Cowbell”.  The “More Cowbell” skit put a very light hearted spin on the production of the hit song.   After seeing that skit, I can never hear that song the same way. The cowbell, for as small a piece it plays, is a huge part of the song.

The same can be said for the hardware that is used in Semiconductor manufacturing tools.  Tool control boils down to controlling the hardware. Without controlling the hardware, the UI and factory automation will not amount to much if the robot doesn’t move. Everything from the robot, down to a simple presence sensor on a load port is needed. What may seem to be the simplest device can be the most prominent.  Each device plays an important part in the process. 

A Cimetrix blog post on March 15, 2016 entitled CIMControlFramework Work Breakdown, identifies driver integration as one of the first steps that needs to be done in the work breakdown for a CIMControlFramework (CCF) application. It may seem intimidating to create a driver to control hardware. There is the need to connect to the device. There is some number of commands and possible responses to deal with.  It can be overwhelming, but can be conquered by understanding what needs to be done to control a device through a driver.

Let’s look at how to go about developing a driver.

1. Understand the interface to the device using any and all documentation available.  The documentation will provide information on how to send commands and interpret the responses.
   1. Does the device control only one device or many?
   2. What is the communication protocol to the device?
      1. TCP/IP
      2. Serial ports
   3. What are the commands?  How are the commands composed?
   4. What are the responses?
   5. Will the device need to be polled?
   6. Will the device send unsolicited messages? 
2. Understand what needs to be controlled on the device for the tool. 
   1. Will you only need to use a subset of the interface or the entirety of the interface?  If just a subset, then there is only a need to write those initially.
3. Writing code to “talk” to the device
   1. Do you have a simulator for the device?
      This one is important, especially if the hardware has limited availability.  If needed, a simple simulator can be developed to at least validate communications, then expanded over time to simulate faults or other conditions.
      
      As the tool begins to come together, each simulator will become invaluable when developing the other parts of the tool and coordinating the devices together. 
   2. Unit tests can be useful to verify that the driver behaves as expected before using on actual hardware.  Unit tests can also provide regression testing should changes be made to a driver.
      Some areas to consider unit testing;
      
      1. Handling of failure to connect
      2. Handling of failure to send to the device or receive from the device
      3. Handling of return values
   3. Start out simple, just get a connection to the device to begin with.  Next send a simple command and inspect the response.  Create a success and build upon the successes!

In the end, a driver will be sending commands and getting and interpreting a response. For every device you create a driver for you’ll also become the expert on that device.

Even though it can be intimidating to start, developing drivers is one of the fun parts of tool development. There is nothing more exciting than seeing the hardware begin to dance in the fashion that has been choreographed in your software

CCF provides utilities and examples to help create drivers for your hardware and easily integrate them into the application, to assist you to orchestrate and provide more cowbell in your tool control. 

To learn more about CCF, visit the CIMControlFramework page on our website!