Industry News, Trends and Technology, and Standards Updates

Equipment Control Logging Benefits

Posted by Derek Lindsey: Product Manager on Mar 8, 2018 11:02:00 AM

markets-timber-logging.jpg

Equipment control applications are highly complex and have many moving parts that require a high level of coordination. Because of the high degree of difficulty, problems are bound to crop up. Sometimes the problems are related to a hardware issue. Sometimes the problems are caused by operator error. Sometimes problems are timing related. Sometimes problems happen infrequently. Regardless of the frequency or the cause of the errors, how do you go about debugging issues that happen in the field if you are unable to attach a debugger to the application?
 
The answer is logging.

As part of the CIMControlFramework (CCF) product for creating equipment control applications, Cimetrix developed a logging package. Our logging package has two parts – collecting the log messages and analysis of the messages.

The logging package allows you to assign a source and a type for each log message. The source specifies where the log message originated. The type is a category that can be used to route the log 

messages to specific output locations called log sinks. We have found the most useful log sink to be a text-based log file. The logging package can be configured for the types of messages to log. It can also be configured for how long to keep log files and how many to keep. This helps keep hard drives from getting too full.

logging.bmp

The temptation for many users is to enable all log messages while developing the equipment control application and then turn all the logging off when the equipment ships to the factory. Cimetrix recommends leaving as much logging enabled as possible. This will help you avoid trips to the fab when a problem arises that can be solved via the logging package. Some clients worry about resource usage by the logging package. We have found that the impact of the logging package is light enough that it is advantageous to leave it on all the time.

The Cimetrix logging package was such a success in CCF, that we have started using the logging package in all Cimetrix products. The logging package has earned rave reviews from Cimetrix product users. Here are a few quick examples that show how valuable logging is:

1. An OEM customer called in a panic because because an end user was withholding payment due to a timing/throughput issue in the application. Together Cimetrix and the OEM reviewed the log file. Using some of the LogViewer analysis tools we were able to isolate and identify the problem within 30 minutes. The OEM was able to confidently tell the end user that they had found the problem and a fix would be available within the next software release. Because the OEM was able to support them so quickly remotely, the end user had confidence in the OEM and released the payment.

2. At Cimetrix, we often hear, “This only happened once, but…” With logging always enabled, it is possible to diagnose problems after the fact. This is especially important for problems which occur infrequently. Users of the Cimetrix logging package are able to resolve issues that happen only rarely.

3. Occasionally an equipment control application will deadlock – two different modules are waiting on each other and neither is free to proceed. Using the LogViewer’s Callstacks plug-in, in conjunction with the Timing Chart plug-in, make the process of diagnosing the deadlock much easier.

logging-1.png

4. An end user called up their OEM equipment provider because the software stopped unexpectedly. They wanted to OEM to put someone on a plane immediately to come diagnose the problem. The OEM was able to view the log file to see that an operator had stopped the tool without the supervisor realizing it. When asked, the operator confirmed he had stopped the tool. Crisis averted. No plane ride required by the OEM to satisfy their customer!

5. A client came to Cimetrix for a training class. This client brought in a contractor to attend the class as well. Part of the Cimetrix training was used to review the logging package. During a break in the training, the contractor approached the instructor and asked if he could purchase the logging package separately for use in his other contracts because he could see several applications that would benefit from the power of the logging package.

6. Cimetrix is continuing to add useful plug-ins to the LogViewer. We recently added an E84 (automated material handling system) plug-in to assist in implementing and debugging material transfer. LogViewer allows users to implement their own custom plug-ins for analyzing data important to them.

logging-2.png

These are just some of the success stories we have heard about in relation to the logging package. With equipment control applications and factory automation, there will always be issues to be addressed and opportunities to root cause unexpected behavior. Having a powerful logging package makes that process much easier.

 

Topics: Equipment Control-Software Products, Customer Support, Cimetrix Products

Creating a SECS/GEM interface for equipment automation using the Cimetrix CIMConnect toolkit

Posted by Jesse Lopez: Software Engineer on Nov 15, 2017 12:30:00 PM

Adding a SECS/GEM interface to an equipiment is the first step in automation. Without the proper toolset, this can seem like an overwhelming endeavor. The CIMConnect™ toolkit provides developers and integrators with the ability to quickly create a SECS/GEM interface and the power to perfect it.

Purpose
Recently I was introduced to the Cimetrix CIMConnect tookit. I had the opportunity to attend a hands-on client training event. Though my knowledge of SECS/GEM was minimal, within three days, I learned the basics of implementing a SECS/GEM interface using CIMConnect and want to share some highlights of that very positive experience.

CIMConnect
CIMConnect provides a robust software development kit that helps developers implement and manage a SECS/GEM interface from their equipment control application. CIMConnect is always current with the latest version of required SEMI standards which simiplifies the process of producing a GEM-compliant interface. When CIMConnect is installed, it comes with multiple tools that make development and testing straightforward and efficient.

CIMConnect Sample projects
CIMConnect samples provide a functioning example of a SECS/GEM application. Sample projects are available in C#, VB.NET, and C++. I will be referring to the C# sample since that is what I used during training.

This sample provides a “known-good” environment that provides a way to accelerate development by taking care of the essentials. I was able to focus on debugging the scope of what I was working on in my application, rather than questioning the SECS/GEM connectivity aspects.

C# Sample Features

  • Processing Simulation: The sample provides a loop that simulates equipment operation. This includes triggering events and updating variable values. 
  • EMService Initialization: When the Sample is compiled and run, CIMConnect is initialized and GEM communication is started.
  • GEM Operator Controls: GEM communication status is displayed in real time using GEM state machines. Communication can be controlled from the sample’s user interface.
  • Multi-threading Examples: Data is processed in separate threads. This is a good practice and allows the user interface to remain responsive while data is effectively processed asynchronously. 
  • Delayed GEM Communication Initialization: This demonstrates the concept of waiting for the equipment to be ready during initialization. 
  • Trigger Events: Events are triggered from the process simulation loop. As events are triggered, related variables are updated.
  • Get and Set Variable Values: This sample provides multiple examples of programmatically getting and setting variable values of varying data types.
  • Set and Clear Alarms: An example alarm can be set and cleared by toggling a checkbox in the user interface. 
  • Terminal Services: Terminal services provide an example of effective logging by displaying real-time messages to the equipment user interface.
  • Remote Commands: The sample allows the user to start and stop the processing simulation by sending a SECS-II message from the host.

Training process
Training is very interactive; the instructor demonstrates a new topic, and then allows the trainees time to try it out. When presented with a new feature to try out, I found it beneficial to initially create a button or checkbox to ensure the new feature worked. Next, I embedded the feature into the application. Breaking each process into these two steps removes ambiguity and avoids unnecessary debugging.

The pace was set by the client. The instructor was available to provide assistance as needed. Though the training follows a curriculum, each session is custom tailored to the needs of the client who requested the training. 

My Application
I had created a C# application prior to training. My application read in an XML recipe and simulated wafer processing. Having a working application to modify during training was very beneficial, since it simulated a real-world practical implementation.

Adding the SECS/GEM interface
The first step was to initialize CIMConnect. This step was simplified by extracting the Initialization functions from the sample project. Once I could observe that CIMConnect was initialized, I was able to move on to adding the SECS/GEM functionality.

API Calls
My application sends API calls to, and receives call backs from CIMConnect. The API calls were somewhat difficult to understand initially due to the customization each call allows.

Wrapper functions
The sample project provides several useful wrapper functions that implement API calls. The overhead of API calls is handled inside the wrapper. The benefit of using wrapper functions is that the developer can focus on whether the result matches his/her expectations rather than whether the API call is incorrect.

After my success using wrapper functions to call APIs, I started to modify and make my own wrapper functions. Eventually I became comfortable calling the APIs directly.

Equipment Configuration
CIMConnect lets you statically define events, alarms, variables, and other attributes in a configuration file. In my file, I created multiple variables that related to my application. Later I learned that my application could dynamically define items instead. Also, my application could programmatically override configured attributes. I think these features would benefit companies that produce multiple equipment types with slight variances.

Adding Events and Alarms
The first event that I created was to let the host know when a FOUP had landed on the load port. I used the SendCollectionEventWithData() wrapper function to trigger the event and increment a variable I had previously defined in the configuration file. This variable provided me with a count of FOUPs that had landed on the input port.

Using the AlarmSET() and AlarmClear() functions, I created 3 alarms. Since I didn’t have hardware such as an EMO button, I used check boxes to toggle each alarm’s behavior.

cimconnect_gettingstarted_1.pngMy application with a SECS/GEM interface. 

Developing Using the CIMConnect Control Panel
The CIMConnect Control Panel is a graphical user interface utility that provides a way to observe the inner workings of CIMConnect.

During development, I used the control panel frequently. I could watch the alarms status change as I toggled each checkbox in my application. Event history and alarm history provided real-time updates. I could change variable values and trigger events from the control panel and verify results on the host without needing to constantly modify my application.

I watched the GEM communication status change on the control panel as I used my application’s GEM control. I could also change the status on the control panel and watch it change in my application.

cimconnect_gettingstarted_2.png

CIMConnect Control panel 1.15.0

Host Testing with GEM Host Messenger
CIMConnect comes with GEM Host Messenger, a host application that allows the user to send and receive SECS-II messages to/from the equipment.

Using GEM Host Messenger, I could easily connect with my application. GEM Host Messenger displays and decodes messages into an easy-to-read format.

I could send S2F21 messages “START” and “STOP” to control processing on my application. It was very satisfying to see my once-standalone application being controlled remotely.

cimconnect_gettingstarted_3.png

Gem Host Messenger 1.0.0

Help Documentation, Tools, and Support
CIMConnect provides an in-depth help file and developer’s guide. I found myself referencing these frequently to get details on different functionality available in the extensive CIMConnect libraries.

Conclusion
CIMConnect allowed me to rapidly develop a SECS/GEM interface and implement it into an already existing program. With CIMConnect training developers unfamiliar with SECS/GEM can learn the basics in as little as 3 working days. Although this was a simple example, CIMConnect has the power and functionality to facilitate projects on any scale.

Find out more
To find out more about CIMConnect and to request a technical product overview or product demo, visit the resources page now.

CIMConnect Resources

Topics: SECS/GEM, Smart Manufacturing/Industry 4.0, Cimetrix Products

Implementing CIM300

Posted by Brent Forsgren on Oct 26, 2017 11:34:00 AM

I have fond memories as a kid spending Saturdays working on the family cars with my dad. We would dive in to taking things apart and putting them back together again. Whatever the problem was we could figure it out and fix it. With cars from the 1960s and 1970s, there wasn’t too much risk with this approach to car repair. Today, I still like to do my own car repairs when I can. But cars nowadays are far more complicated and compact. I have learned that I can’t just jump in and wing it with any hope of getting it done right or in a timely manner. My experience has taught me to rely on the experience of others, learn from their lessons and save myself from late nights asking, “what have I gotten myself into?”

Cimetrix CIM300TM tool kit out of the box has already implemented a lot of the GEM 300 work for you. Notice I said “a lot” and not “all” of the work for you. To complete your GEM 300 application, your software will have to integrate with CIM300. The GEM 300 standards can be quite complex and some of the scenarios have intricate details. CIM300 provides a rich set of APIs and callbacks to help you implement a compliant GEM 300 solution. The key to success is knowing how to use the APIs and callbacks for the different GEM 300 scenarios.

The SEMI E87 Carrier Id Status state model, pictured below, is just one of many state models defined in the GEM 300 standards.

Carrier ID Status State Model for CIM300Figure 1 CARRIER ID STATUS STATE MODEL

There are several transitions in this state model and intricate conditions that determine which transition should be triggered. CIM300 supports this state model, but it requires interaction with your application to know which transition to make in the state model. In my experience, most people handle the happy path scenarios correctly, whether they're “winging it” or had formal training. However, I have rarely seen people handle the error scenarios correctly, without training on GEM 300 and CIM300. While understandable, error scenarios are often hard to follow and the implementation differences are subtle. The risk of doing it wrong in the software will execute the wrong transition in the state model, which in turn sends the incorrect event to the GEM host. The wrong event could really mess things up for the host. In both the happy path and error scenarios, the CIM300 API to call is the same:

CMSLib::CCxE87CMS::CarrierAtPort

However, how you specify the parameters to the call, it is different for each scenario. The differences in how you call the API will trigger different transitions in the state model. Our documentation for this one API call alone is longer than this entire blog post. That is how important it is to get it right. In addition to our product documentation, Cimetrix also provides CIM300 training and sample applications illustrating how to use our products.

I strongly recommend taking advantage of our CIM300 training. Training is the best first step to integrating CIM300 with your tool application. Training is typically a week long and provides an overview of the GEM 300 standards as well as hands-on experience using CIM300. The goal for Cimetrix in training is that by the end of the week-long training, clients have completed an implementation of a GEM 300 happy path scenario. That is, you receive hands-on experience using CIM300 to implement carrier verification (SEMI E87), creating and running a process job (SEMI E40) and control job (SEMI E94), tracking substrates (SEMI E90), and tracking equipment performance (SEMI E116).

Make sure you also leverage the sample applications that accompany CIM300. The sample applications provided with CIM300 give a jumpstart on integrating CIM300 with your own application. You can use the sample application as a reference for how to use our APIs and callbacks, copy/paste portions of the code into your own code, or use our application as a starting point for your own software. If you’re like me, you like having working source code you can refer to for concrete examples of how to do things and to see how things should work together.

If you dive right in and start implementing CIM300 without training or mentoring from an expert, you may find yourself spending a lot of late nights asking yourself, “what have I gotten myself into?” A little training goes a long way in simplifying the implementation!

Find out more about CIM300 or request a Technical Product Overview and/or Product Demo today!

Request CIM300 Resources

Topics: Doing Business with Cimetrix, Cimetrix Products

EDATester Product Launch: EDA/Interface A Freeze II Testing

Posted by Jesse Wright; Software Engineer on Jul 25, 2017 11:30:00 AM

In a world of automated equipment, having tools to automate the testing of an equipment’s implementation of the SEMI EDA (Equipment Data Acquisition) standards (also known as Interface A) is invaluable. Cimetrix is proud to announce an integrated solution that supports the broadest range of use cases in EDA/Interface A testing - the Cimetrix EDATester™. EDATester is a tool that will help organize, streamline, and automate the testing process while also providing other analytical capabilities. 

Cimetrix knows that testing an equipment interface is not simply a one-time event; rather, tests should be performed in the OEM’s facilities throughout the development process and before final shipment, upon delivery to the customer’s factory, and even after the equipment has been placed into full production. Cimetrix EDATester is designed to do exactly that.

EDATester4.png

What do we really mean by “testing?” What are we testing? Since the scope is very broad, let's frame the answer in a few distinct categories.

Compliance Testing

Does the equipment’s EDA interface behave correctly based on the SEMI E120, E125, E132, and E134 standards and all the services defined therein? To answer this question, we make use of the ISMI EDA Evaluation Method. This document contains a set of functional evaluation procedures that “tests” the equipment’s implementation of the standards. These procedures check for things like ACL privileges and roles, establishing and terminating communications sessions, managing (or preventing the management of) Data Collection Plans (DCPs), and even looking for the proper notification of metadata revisions. If everything works as expected in these procedures, that equipment would be deemed “compliant.”

EDATester uses ISMI’s functional evaluation procedures as guidelines, and implements tests that are automated for all client-side actions. A process that might have taken multiple days to execute manually can be done in minutes, even when some interaction with the equipment itself is required; the fully automated tests that require no user interaction with the equipment can be run in seconds.

Performance Testing

Everything might look great on the client side with the ability to define a DCP, activate it, and start receiving data; but how many DCPs will the equipment actually support? How fast can I sample the parameters I want to collect in my Trace Requests without overloading the equipment’s EDA interface? Even if I could do this manually, how would I begin to answer this question?

EDATester automates multiple iterations of performance testing using different variations of DCPs while analyzing the timestamps of the E134NewData messages to determine the integrity of the actual sampling rate. Having such tests helps you determine whether the equipment can handle a new DCP in response to a process engineering request, or if the equipment supports the full range of performance requirements agreed to in the purchasing specifications. To this end, you can specify testing configurations for things such as:

  • Number of simultaneously active DCPs 
  • Trace Request Sampling Interval
  • Number of parameters per Trace Request
  • Group Size for message buffering
  • Timing tolerance for expected vs. reported Data Collection Report (DCR) timestamps

Conformance Testing

The testing tool in practical use across the industry for measuring an equipment’s conformance to the SEMI E164 EDA Common Metadata standards is called the Metadata Conformance Analyzer (MCA). It uses a set of .xml files describing the metadata model as input, analyzes the model according to the requirements of E164, and provides feedback.

EDATester currently generates the .xml input model files required by the MCA, and may eventually incorporate the model conformance testing functions as well.

Summary

Having the correctly sized wrench when you need to apply the proper torque to a bolt is helpful and sometimes necessary—at least you can get the job done. But when you have hundreds of bolts to insert and tighten precisely, wouldn’t you rather have an adjustable ratchet? Or an air ratchet?

Whether it’s to test and characterize the EDA interface on a new equipment type,  verify that a software update to a production piece of equipment has been installed correctly, or debug an interface performance issue that has somehow arisen in production, the Cimetrix EDATester is the right tool to have in your arsenal to quickly, effectively, and thoroughly “test” an equipment’s EDA interface capabilities. Don’t waste another day with manual processes that leave you guessing. Get in touch with us today to find out more about the EDATester product. 

Topics: EDA/Interface A, Cimetrix Products

Implementing CIMPortal Plus

Posted by Derek Lindsey: Product Manager on Jul 7, 2017 12:07:00 PM

Toolkit.jpg

Generally, when I do a DIY (do-it-yourself) project around the house, I spend the majority of the time searching for my tools. The other day I was helping a friend with a project. He had a well-organized tool box and it seemed that the perfect tool was always at his fingertips. I was amazed at how fast the project went and how easy it was when the right tools were handy.

In April of 2016, we published a blog called OEM EDA Implementation Best Practices that outlined ten things to consider when designing an equipment-side EDA / Interface A solution to fit your needs. This blog post analyzes a few of those recommendations and looks at how using the Cimetrix EDA products CIMPortal Plus, ECCE Plus and EDATester (a well-stocked and organized tool box) makes it very easy to follow those recommendations.

The basic steps in creating a useful EDA implementation are:

  1. Determine which data will be published
  2. Build an equipment model
  3. Deploy the model
  4. Publish the data from the equipment control application
  5. Set up a data collection application
  6. Test the interface

The blog post mentioned above states, “Since the content of the equipment metadata model is effectively the data collection contract between the equipment supplier and the factory users, your customer’s ultimate satisfaction with the EDA interface depends on the content and structure of this model.” Before building your model, you need to determine what data the equipment will make available for collection. CIMPortal Plus has the concept of a Data Collection Interface Module (DCIM) that publishes this data to the EDA server. The engineer building the model will map the data from the DCIM into the equipment model.

Once the mapping of the data is complete, the engineer will need to put this data in a format understood by the server. CIMPortal Plus provides a utility called Equipment Model Developer (EMDeveloper – pictured below) that makes it easy to create the hierarchy of your equipment (SEMI E120) and embed the data from the DCIM into that model (SEMI E125). If you use the tools and best practices provided in EMDeveloper, your equipment model will conform to the SEMI E164 (EDA Common Metadata) standard as well. This can be very useful when writing data collection applications so conformance to E164 is being required by more and more fabs. The E164 standard was developed to encourage companies using Interface A connections to provide a more common representation of equipment metadata based upon the SEMI E125 Specification for Equipment Self-Description. This makes data collection more uniform across these pieces of equipment.

CIMPortalPlus_Blogimage1.png

Once the model is created and validated, it is deployed to the CIMPortal Plus server. The server is the component that manages and tracks all data collection plans, reports, tasks, access control and timing. 

With the DCIM information embedded in the model (described above), it is easy for the equipment control application to push the data to be published to the EDA server for collection. This is done by using a simple API available on the DCIM interface.

In addition to CIMPortal Plus server capabilities, Cimetrix has other products available to help with client-side data collection. ECCE Plus is an industry approved method for manually testing EDA implementations. For users who need to create client-side data collection applications, Cimetrix also provides EDAConnect - a powerful library that handles all the connection details and allows developers to concentrate on the specific data collection and analysis tasks.

Fabs receive a wide variety of equipment with EDA implementations from numerous vendors. They want to use a single verification application to make sure that all EDA implementations are compliant to the EDA standards. That’s where EDATester comes in. EDATester is a new product that allows users to quickly and accurately verify EDA standards compliance by automating the test procedures ISMI EDA Evaluation Method that were defined specifically for this purpose. If you use Cimetrix products to implement your EDA interface, you are guaranteed to be compliant with the SEMI EDA standards. But whether you use Cimetrix products to implement your EDA interface or not, you (and your fab customer) want to rest assured that your implementation is fully compliant. Moreover, you’ll want to know that you’ve met the fab’s performance criteria for your equipment interface. To support this use case, the EDATester also allows users to quickly profile the performance of EDA data collection on a piece of equipment so that fabs and those using the data will know the boundaries within which they can successfully collect equipment data.

With the well-stocked EDA tool box provided by Cimetrix, following the EDA best practices in creating an efficient, standards-compliant EDA interface becomes a snap.

Topics: EDA/Interface A, Cimetrix Products

CCF Series Wrap-up

Posted by Derek Lindsey: Product Manager on Apr 12, 2017 11:00:00 AM

One of the habits outlined in Stephen R. Covey's book, The 7 Habits of Highly Effective People, is to "Begin with the End in Mind." He goes on to explain that beginning with the end in mind means to "begin each day, task, or project with a clear vision of your desired direction and destination, and then continue by flexing your proactive muscles to make things happen.”

Beginning an equipment control project with a clear vision of your desired destination makes it much more likely that you will have a successful project. A blog post titled CIMControlFramework Work Breakdown dated March 15, 2016 outlined the tasks necessary to create a first-class equipment control application using CIMControlFramework (CCF). Since that initial blog post, Cimetrix has explored each of the tasks labeled in the work breakdown structure in greater depth in their own blog posts as follows:

Looking back from the successful completion of a CCF equipment control application makes it clear that the work breakdown vision from the beginning helped gain that success.

You can also reference the following blog posts related to CimControlFramework:

CIMControlFramework Dynamic Model Creation

Learning from Others

Build vs. Buy

WCF and CIMControlFramework

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

Topics: Equipment Control-Software Products, Cimetrix Products

Testing Your CCF Application without Waiting for Hardware

Posted by Brent Forsgren on Mar 29, 2017 11:26:00 AM

You've heard the expression, “you can’t make an omelet without breaking a few eggs.” That is, you shouldn't be surprised if you end up destroying a few things in the process of achieving your goal. When it comes to building a new piece of equipment, do you really want to risk breaking a few wafers, or worse yet, hurting personnel or equipment, to develop your new tool control software? I think everyone would answer with a resounding “No!”
In the March 2016 blog post on CIMControlFramework Work Breakdown, simulation was listed as one of the eleven points to be taken into consideration when developing an equipment control application using CIMControlFramework (CCF). In addition to personnel and hardware safety, there are other reasons to use simulation when developing equipment control applications, namely:

  • You want to start testing your software as early as possible, often this is before your equipment is finished. Then when your equipment is ready, integrating your tested software with your hardware will proceed smoothly and minimize delays in your time to market.

  • If you have an existing tool and you’re upgrading your tool control software, scheduling software testing time while still allowing other engineering teams (mechanical, process, etc.) to get their jobs done is challenging.

  • The hardware components that comprise your tool, e.g. robots, load locks, and process modules, will not be finished at the same time. You want to test your software with real hardware as soon as possible, while still simulating the missing equipment components.

  • Tool time is valuable. It's nice to be able to test your software without using the valuable tool time where possible.

  • It is likely that your tool will have more than one configuration, customized for each of your clients. Setting up different hardware configurations in order to develop and test your tool control software is time consuming. You want to be able to test your software for all of your equipment configurations in timely manner.

Wafer_tool-CCF-Simulator.jpgCCF provides a simulator that you can use to test your tool control software during development, and before you run the software on the real hardware. Running against a simulator first will expose issues in your software without damaging people, material and hardware. CCF’s simulator simulates real hardware, which means it is not necessary to add conditional checks in your software to check when it is running with a simulator versus real hardware.

CCF’s simulator features include:

  • Simulation of atmospheric and vacuum hardware components, e.g. load locks, vacuum pumps, vacuum gauges, etc.

  • Simulating delivery and removal of carriers to load ports, both manually and automatically using E84 handshaking.

  • Simulation of robot moves for both atmospheric and vacuum robots.

  • Simulation of I/O.

  • Simulation of hardware faults, to safely test error handling.

  • Simulate running single jobs or cycling wafers for endurance testing.

Additionally, CCF provides other tools to help you test your software without hardware.  CCF provides a Visual Studio template, and a number of classes and interfaces to aid you in developing simulation software for your process module or other custom hardware. Use the Visual Studio template to start development of GUI user controls for simulated hardware. Implement CCF’s I/O simulation interfaces for generating inputs to your tool control software and writing outputs to your simulated hardware. Tie the two sides together using CCF’s simulation client and server to handle the communication.

With these CCF tools, you can develop and test your tool control software without hardware. When hardware is available, you can test your software with your tool with a high degree of confidence that it will perform as expected.

Avoid “breaking a few eggs” and develop your tool control software with CCF and test it using CCF simulation features.

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

Topics: Equipment Control-Software Products, Cimetrix Products

Using CCF I/O Helper Functionality

Posted by David Warren: Director of Software Engineering on Mar 14, 2017 12:00:00 PM

“Can you hear me now?”

A Cimetrix blog post on March 15, 2016 entitled “CIMControlFramework Work Breakdown”mentions that CIMControlFramework (CCF) includes ASCII serial drivers and IO providers.  What does that mean and why should you care?

Factory Automation Software
Equipment automation is all about creating software that controls hardware—combining individual components into a harmonious whole, with each piece playing its own unique part.  A critical aspect of control is the ability to communicate—and that is where CCF’s ASCII serial driver and IO providers can help you create your equipment application.

The .NET Framework, like many software development platforms, provides built-in support for serial ports and TCP/IP ports.  This built-in support is great for low-level, binary communication, but hardware devices often just need a simple ASCII connection.  For such hardware, CCF’s ASCII serial driver frees you from worrying about the connection and the underlying implementation.  You can focus on the content of the message instead of the mechanics of delivery.  It’s like using a telephone—you want to focus on the conversation rather than worrying about how the sounds are transmitted between the phones. 

Another common class of hardware uses signals to communicate.  These signals can be as simple as only having two possible values (think “on” and “off”) or having a range of values, like a temperature.  Each signal also has a direction—it is either an input or an output.  For input signals, the value is determined by the hardware and read by the software.  Output signal values are determined by the software and sent to the hardware.  For example, control software might use an output signal to turn a light on and off, and an input signal from a photocell to verify the light is on or off.  This class of hardware is called I/O (short for input/output) devices and is supported by CCF.

CCF includes support for communicating with ASCII serial and I/O devices to make your job easier.  Don’t spend your time and effort asking the hardware “Can you hear me now?”  Use CCF and focus on combining the parts into the harmonious whole. 

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

Topics: Equipment Control-Software Products, Cimetrix Products

Storing Data in a CCF application

Posted by Derek Lindsey: Product Manager on Mar 8, 2017 1:00:00 PM

In Sir Arthur Conon Doyle’s A Scandal in Bohemia, Sherlock Holmes tells Watson, “It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

In a March 2016 blog post on CCF work breakdown Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the tasks in the work breakdown is to determine what kind of data collection and storage is to be used in your CCF application and determine how that data is to be stored.

User_Interface_Sm_CCF_1-5-17.jpg

CCF provides several mechanisms for collecting and storing data. These include:

  • History Objects

  • Full GEM Interface

  • Full EDA/Interface A Interface

  • Centralized DataServer

The remainder of this blog post will look at each of these items in more detail.

History Objects

In early iterations of CCF, users noticed when using logging, there were certain messages that they wanted to be able to query without the overhead of having to search all log messages. To help accommodate this need, History objects were introduced. Some examples of these objects in CCF are EPT History, Wafer History and Alarm History. When an important event happens in the life of a history object, a log message is written to a database table (configured during CCF installation) that corresponds to that type of object. That database table can be queried for the specific historical information for only that type of data. 

Full GEM/GEM 300 Interface

As described in a CCF blog post from February 15, 2017, CCF comes standard with a fully implemented GEM and GEM 300 interface. The GEM standards allow users to set up trace and event reports for the collection of GEM data. No additional programming is required by the application developer to have access to the GEM data collection.

Full EDA/Interface A Interface

The same blog post of February 15th also states that CCF comes standard with a fully implemented Freeze II and E164 compliant EDA interface. EDA can be used to set up data collection plans based on Events, Exceptions and Traces. With the E157 standard and conditional trace triggers, EDA makes it easy to zero in on the data you want without having to collect all data and then sift through it later.

Centralized DataServer

In order to create, initialize, populate and pass data, CCF uses a centralized DataServer object. The DataServer is responsible for creating the dynamic EDA equipment modelas well as populating CIMConnect with Status Variables, Data Variables, Collection Events and Alarms. All this is done at tool startup so that the data available exactly matches the tool that is in use.

Data is routed to the DataServer which then updates the appropriate client – such as EDA, GEM or the Operator Interface. An equipment control application can register to receive an event from the data server when data changes. Users can key off of this event to capture that data and route it to a database as desired. Since all tool manufacturers have different requirements for which database to use and how data is written to that database, CCF leaves the actual SQL (or equivalent) commands for writing the data to the equipment application developer.

With CCF Data collection and storage is … Elementary.

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

Topics: SECS/GEM, EDA/Interface A, Equipment Control-Software Products, Cimetrix Products

CCF Provides Fully Implemented GEM300 and EDA Interfaces

Posted by Bill Grey: Distinguished Software Engineer on Feb 15, 2017 1:00:00 PM

What does this mean and why should I care?

The SEMI standards for 300mm Semiconductor Manufacturing Equipment can be an overwhelming burden of information to understand, let alone implement.

The GEM standards comprise over 450 pages of documentation: E4, E5, E30, E37, E37.1, E172, E173.

The 300mm standards add another 280 pages: E39, E40, E87, E90, E94, E116, E157, E148.

And the EDA standards pile on an additional 480 pages: E120, E125, E128, E132, E134, E138, E164.

That’s over 1200 pages of standards documents filled with requirements and implementation information. 

On top of that GEM and EDA collect data differently from the equipment.  See a post we did on data collection for more information on those differences.

Implementing the requirements defined in those standards without an SDK would be a very brave undertaking.  Even with SDKs for the standards, it would be a fair amount of work, when all you really want to do is get your equipment automated.

In addition, it is very important that those standards be implemented correctly in order for your equipment to be smoothly integrated and accepted into each fab.  Different fabs use the standards slightly differently or have additional requirements.   This requires experience.

GEM300 and EDA standards implementation is a very large burden.

semi standards difficult burden

So what does this mean?

One of the large tasks for the EDA standards is defining a hierarchical model of the equipment and what data it can produce in XML per the schemas defined in the standards.   Creating the initial model and keeping it up to date as the equipment evolves is a tedious task.  In addition, that model must be conformant to the E164 standard (which has over 10 pages of requirements on its own).   See our blog post on conformance testing. CCF does this for you, producing an E164 compliant EDA model in the background based on your CCF programming. See our blog post on CCF dynamic model creation further details.  CCF also builds the GEM interface model for you at the same time.

Further, CCF is completely GEM compliant and 300mm compliant, using the Cimetrix CIMConnect and CIM300 products which have been successfully deployed in every 300mm fab around the world on many different equipment types.

Twelve hundred pages of standards, compliantly implemented, at no additional effort.  That is what this means.

Turn that donkey into a goat and use CCF.

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

 

Topics: SECS/GEM, Equipment Control-Software Products, Cimetrix Products