Industry News, Trends and Technology, and Standards Updates

Create a Scheduler Using CCF

Posted by Derek Lindsey: Product Manager on Dec 14, 2016 11:30:00 AM

Shel_Silverstein_MelindaMae.jpg

How do you eat a whale? One bite at a time. 

In a March 2016 blog post entitled CIMControlFramework Work Breakdown, Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the things to consider is how you want to control the material moving through the tool – or scheduling of material. This blog post delves a little deeper into the scheduling aspect of equipment control applications.

Doctoral dissertations and entire books have been written to discuss scheduler theory. Because of sheer volume of information available regarding scheduling and scheduling theory, the topic can come across as a little (or a lot) intimidating. CCF aims to take the scare factor out of scheduling and allow equipment control application developers to fully control the movement of material through their tool.

CCF provides a framework for a reactive, rule-based scheduler. You, as the application developer and in conjunction with your customer needs, get to decide what decisions are important when creating your scheduler. One of the first things you need to do when developing a scheduler is to ask questions to help you determine the rules for scheduling. Some questions you may ask:

  • What is the most important thing I am attempting to accomplish with my scheduler?

    • Is throughput the most important?

    • Is path predictability most important?

  • How can I ensure that when I pick material up that there is a destination available to put it?

  • If two components need a robot to take action (pick up or place material), which action takes precedence?

  • Do the process chambers need to be prepared before receiving material to process?

  • What is the wafer flow scenario (is there a specific order that material must follow)?

    • Does the material need to be aligned before processing?

    • Does the material need to be acclimatized before processing?

    • Does the material need to be cooled before returning to the carrier?

  • Are there any maintenance tasks that have to be performed periodically in the tool that have to be accounted for in scheduling?

This is by no means an exhaustive list of questions, but these are the types of questions that need to be answered when creating your scheduler. 

The scheduling framework provided by CCF allows you to translate these rules into C# conditional statements. No proprietary scripting languages need to be learned. No specific configuration training is required. C# developers can use industry standard IDEs to put these rules into scheduling practice.

Once the scheduling rules are determined, it can still be intimidating to know how to start creating your scheduler. Cimetrix provides a few basic, as well as more advanced,of  scheduling labs that fully explain how to translate your rules into a functional scheduler. These labs can be completed in as little as a few hours. The labs explain the scheduling theory used by Cimetrix and allow users to create functional schedulers in a short amount of time. Many CCF users can create a working scheduler in one week.

Cimetrix also provides complete working examples of atmospheric and vacuum schedulers as part of CCF. Another lab provided by Cimetrix clearly describes how to start with one of these working schedulers and modify it to suit your scheduling needs.

The CCF scheduling framework allows the software to be hardware agnostic. In other words, it is not tightly coupled to device drivers. This allows tool manufacturers to change out hardware without having to make scheduler changes to support the new hardware.

Although scheduling may seem like an intimidating whale to eat, CCF helps break the tasks down into bite-sized chunks.

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

Topics: Equipment Control-Software Products, Cimetrix Products

Create Device Drivers Using CCF

Posted by Tim Hutchison: Senior Software Engineer on Dec 6, 2016 11:30:00 AM

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.

Keep_Calm_Cowbell.jpg

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!

Topics: Equipment Control-Software Products, Cimetrix Products

Learning from Others

Posted by David Francis: Director of Product Management on May 10, 2016 2:37:12 PM
blueprint.jpg

Almost everyone I know that has built a house has given me a list of things they would “do differently next time,” but a lot of those same people would also say that they would never build again. So does that mean everything they learned through the process is lost? Is it possible to get it right the first time? Maybe not, but there are a lot of things you can do to learn from the experience of others. For example, you can buy house plans that have been used before and are designed to leverage standard components. Rather than designing and building everything from scratch, you can use pre-built sub systems like fabricated floor joists and manufactured roof trusses. Using proven components saves a lot of time and worry about whether or not they will work properly and as expected. This allows you to focus on the customizations that will make the home meet your unique needs.

Implementing an equipment control application is a lot like building a house. You can design and build a complete control system from the bottom up—building all the components necessary to handle communication with the hardware, display information to the operators, manage user access, log relevant event and data information—but it doesn’t add value to the core competency of your equipment. The best option is to leverage proven design that has been built through multiple prior applications and leverages those lessons learned along the way.

Cimetrix's CIMControlFramework provides all the standard components necessary to build an equipment control application. With working samples for both atmospheric and vacuum equipment, it can easily be customized and extended as needed to meet specific control needs.

There is an old saying that goes, “If you don’t have time to do it right, when will you have time to do it over?”

If you would like to learn more about CIMControlFramework and how it can help you on your next project, give us a call or feel free to contact us here.

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

Topics: Equipment Control-Software Products, Doing Business with Cimetrix, Cimetrix Products

CIMControlFramework Dynamic Model Creation

Posted by Derek Lindsey: Product Manager on Apr 14, 2016 1:00:00 PM

turkey-218742_960_720.jpg

Have you ever watched one of those cooking shows where the chef spends a lot of time whipping up the ingredients to some elaborate dish, and, when it comes time to put the dish in the oven to bake, there is already a finished one in there? If only the real world worked that way. Sometimes it would be nice to be able to go to the oven and have a delicious meal already waiting for you.

The Cimetrix CIMControlFramework™ (CCF) product is unique among Cimetrix products in that it not only provides source code, but also combines several other Cimetrix products (CIMConnect, CIM300, and CIMPortal™ Plus) and takes full advantage of all the features provided by each product.

One of the features of CIMPortal Plus that is used in CCF is the concept of an equipment model. The equipment model describes the data that your equipment provides through Interface A. The tool hierarchy is modeled along with all of the parameters, events, and exceptions published by the tool. It used to be that CCF users had to manually create the tool hierarchy in their base equipment model. CCF would then populate the model with the parameters, events, and exceptions. If the tool hierarchy changed, the base model would have to be modified. It made changing the tool configuration much more difficult.

Starting with the CCF 4.0 release, a base equipment model that is common to all equipment was installed. Generally, CCF users will not need to modify the base model. CCF takes advantage of the modeling API provided by CIMPortal Plus to dynamically add hierarchy nodes to the base model depending on the components that are created in CCF. This new feature makes it easy to change the configuration of the CCF tool because the user does not have to make modifications to the base model and redeploy the package to be able to run CCF.

The dynamically created model is also compliant with the SEMI E164 Common Metadata standard. This compliance is possible because of the dynamic nature of model creation. The required elements of E164 are added to the equipment model dynamically during the startup of Tool Supervisor.

Having a dynamically created Interface A model that exactly matches your equipment structure and is guaranteed to be E164-compliant without having to do any extra work is similar to going to the oven and finding a delicious dish already cooked and waiting for you.

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

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

CIMControlFramework Work Breakdown

Posted by Derek Lindsey: Product Manager on Mar 15, 2016 1:00:00 PM

FirstStepofaThousandMileJourney1.jpg

“A journey of a thousand miles begins with a single step.” – Lao Tzu

“Watch out for that first step Mac, it’s a lulu!” – Bugs Bunny

These quotes by the great philosophers Lau Tzu and Bugs Bunny have more in common than would appear at first glance. At the beginning of a journey you have the element of the unknown. There is excitement that it could be a great journey, but there is also an element of the unknown that may make that first step the hardest to take. If you haven’t put in the preparation for a successful journey, that first step might be a lulu.

Similarly, when starting a new equipment control application, there is excitement for the great end product, but also some element of not knowing the best place to start. CIMControlFrameowrk (CCF) offers a great training program to get you started and many building blocks for helping create a first-class equipment control application. Even with these great starting tools, many users still have the question, “Where do I go from here?”

The first step is to create a work breakdown of what it takes to create a successful equipment control application. There will obviously be tasks that are unique to each equipment control application, but most applications have some common tasks or epic user stories that have to be completed during the project. The order in which these stories are completed may depend on milestones and expectations for when they are accomplished, but they generally all need to be completed during the project.

  • Integrate Devices – CCF provides an Equipment layer with abstractions of most commonly used devices. Integrating these devices into CCF only requires the implementation of the abstract interface.

  • Material Movement Through the Tool – CCF provides a flexible scheduler with complete working examples of different types of scheduling that could be done.

  • Implement the Process Module – CCF provides a process module interface that allows the rest of CCF to communicate with your process module – your secret sauce.

  • Create an Operator Interface (OI) – CCF provides an OI framework that allows commands to be sent and updates to be made. It also provides some default screens that use this interface. It also allows for insertion and use of custom OI screens.

  • Simulation – CCF provides a simulator that can be used in place of real hardware. The simulator can be used to deliver/remove material, perform robot moves, and do simulated IO. This is invaluable in continuing development before the hardware is ready or if there is limited tool time for the developers.

  • Recipes (Process Recipes and Execution) – CCF provides a recipe manager for passing recipes through the tool. The default recipe can be used or custom recipes can be added.

  • I/O – CCF provides ASCII serial drivers and other common IO providers. Custom IO providers can also be included in CCF.

  • Data Collection and Storage – Knowing what data to store and what medium to use for storage is recommended up front.

  • Factory Automation – CCF provides a fully integrated GEM, GEM300, and EDA implementation.

  • Diagnostics and Testing – The CCF logging package is a fantastic tool for debugging your application both on the tool and remotely.

  • Errors and Recovery – CCF provides an Alarms package for signaling of and recovery from error conditions.

By going through CCF training and creating a work breakdown of the tasks that need to be done for your equipment control application, you can ensure that your first step will be the foundation of a successful journey.

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

Topics: Equipment Control-Software Products, Cimetrix Products

Build vs. Buy?

Posted by David Warren: Director of Software Engineering on Feb 18, 2016 1:06:00 PM

Every company that needs software must make a build versus buy decision at some point. Some choices are easy—it makes little sense to build your own office software for word processing, spreadsheets, or presentations. But what if you need software to control specialized physical equipment?

Classic advantages of building your own software are:

  • Canned software is generally targeted to meet many needs for most problems. Custom software is better suited to meet specific and uncommon needs.

  • Canned software has a fixed set of features and it may be difficult to add or remove specific features, which may lead to software that contains unneeded features or is missing features that you do need. Custom software can be built to meet the specifications of a projects and include all the features that are needed and never any that aren’t.

  • The process of developing software builds in-house technical expertise. This expertise can be used to create competitive advantage through higher performance and faster reaction time in meeting the changing needs of the marketplace.

Classic advantages of using standardized software are:

  • Standardized software is generally less expensive than custom software because its cost can be spread across many customers and/or tools.

  • Standardized software can require less time depending on the degree of customization required.

  • Standardized software can be more reliable since it has been tested and used in many different applications.

  • Standardized software may provide more features than would otherwise be available.

Why Not Combine the Best of Both Options?

Brackets_Code.png

Buying a tool control framework can help you build your own tool control software and still get the benefits of using standardized software. The framework can take care of common problems while you focus on items unique to your specific tool. As a framework, features can be removed, replaced, or even modified as needed. You reduce your costs as well as your time-to-market by using a selection of reliable, field-proven features and including only those that are relevant and add value to your control system. You still retain and build your in-house technical expertise to create competitive advantages in controlling your equipment instead of treating tool control expertise as a commodity.

Using a tool control framework can be a smart way to improve your processes by using standardized software that is easy to customize. So why not consider it as an option for your next project?

If you are interested in downloading the data sheet on Cimetrix’ tool control framework software, CIMControlFramework, click here.

Topics: Equipment Control-Software Products, Cimetrix Products

Cimetrix at SEMICON West 2012 - Equipment Control

Posted by Cimetrix on Jun 29, 2012 1:30:00 PM

If you are going to attend SEMICON West in San Francisco, July 10-12, 2012, at the Moscone Center – please visit us at booth #1241 and let us tell you how we can support your next equipment control project using our CIMControlFramework™ equipment automation software.

CIMControlFramework dashboard

As more and more customers use CIMControlFramework software on different tool types (strip tools, MOCVD, defect inspection, chemical deposition, and a host of others), we have also generated training material in the form of labs our customers can use to help them get up to speed faster and learn how to implement designs easier and more effectively.

Come to our booth and take a look. When we demonstrate CIMControlFramework, we will show you the labs we supply with the software. Those labs include not only topics such as installation and fundamentals, but also sections such as scheduling and material movement, user interface development, and I/O and communications.

We can also discuss our product support and training classes that will help get your team up and running on SEMI factory connectivity standards, and their implementation, equipment control, and C# and Agile software development.

We look forward to seeing you at our booth at SEMICON West.

Topics: Equipment Control-Software Products, Events

CIMControlFramework Boot Camp

Posted by Cimetrix on Aug 9, 2011 9:30:00 AM

by Scott Gardner

Senior Software Engineer

I’ve been a software engineer for more years than I care to remember (or than I’m willing to say). My experience includes embedded microcontroller-based applications, database and accounting software, and GUI development. I’ve always been interested in controlling hardware with software but the semiconductor industry and factory automation was not part of my experience. When I became part of the team in May, I was excited to get started, but also somewhat apprehensive. I was concerned about how quickly I would be able to learn all the new material and become a productive member of the team—a daunting task when you consider I had to learn both the new industry and code base. I was prepared to spend many extra hours coming up to speed.

My first day at Cimetrix began with Boot Camp. It seemed like everyone was talking about or working on something to do with Boot Camp. I didn’t know what it was but it sure had everyone busy. It didn’t take long to realize that Boot Camp was all about training.

C  Users rschreck Documents Marketing Blogs CCF Bootcamp BC Class resized 600

This was training in a way I had never experienced before. People from different companies came from all over the country to Cimetrix—our own little United Nations, you might say! One thing that immediately impressed me was the level of enthusiasm among all involved. 

We were introduced to the industry and the science. The physics involved is mind boggling! It was very cool to get to touch a real wafer while learning how they were made. This was training that included not only theory but also practical application—it was very hands on.

The software was equally impressive. Of course we went through the standard installation and demos but that was just the start. The entire CIMControlFramework architecture and tool control design process was laid out, and the trainers presented us with a series of labs that progressively got us deeper and deeper into the Cimetrix software, not only the CCF tool control product, but also CIMPortal (for Interface A) and CIM300 (for GEM 300 connectivity). The best thing about the labs is that by the time we had worked through them we not only had a working system we also knew how the system worked. I still use my completed labs today.

Agile was introduced in a gentle but accelerated way. We did scrum standups twice a day and a retrospective daily. We learned what makes a good user story and how to handle product backlogs and spring planning. We each got to keep a deck of planning poker cards.

Remote collaboration was also given a serious look.  We learned how to use a number of tools in order to communicate effectively with each other and plan sprints. This part of the training brought everyone together as a team and how we need to communicate with the “Product Owner”, who is often the project leader employed by our customer.

C  Users rschreck Documents Marketing Blogs CCF Bootcamp BC Group resized 600

I’ve seen quite a few approaches to development but this was a very different experience for me.  It was obvious that these guys take training seriously. This was training the way training was meant to be done!

Topics: Equipment Control-Software Products, Cimetrix Products

New Features in CIMControlFramework™ 3.0

Posted by Cimetrix on Jul 1, 2011 1:41:00 PM

By David Francis

Product Manager

The creation of a new software product is an exciting process. Often, as was the case with the Cimetrix CIMControlFramework™ (CCF) software, this process begins with a partner that will become the first customer of the product. Cimetrix teamed with Axcelis Technologies to develop a new tool control framework for one of their process tools. A following project with Rorze Automation further developed the framework and produced CCF 2.0. Upon completion of that project, Cimetrix continued the development of the tool control framework to become a standard product that any OEM could use, resulting in the release of CCF 3.0.

The development effort for CCF v3.0 focused on four main areas that improve both the product development capability and the user experience:

  • Tighter integration with Cimetrix connectivity products
  • Faster data analysis
  • Reduced installation time
  • Improved training material

1)      Tighter integration of CIMControlFramework with factory automation components to implement Interface A and SECS/GEM connectivity

We simplified the data configuration so that parameters, events, and alarms are registered at start up and automatically coordinated with the configuration files for the factory automation products.

In the previous versions, CCF was configured to work with a CIM300 or CIMConnect product that was previously installed and configured for the equipment. The problem was that if someone needed to change the connectivity functionality, that change was not reflected in the tool control portion of CCF, or vice versa.  This meant that the required changes had to be implemented twice, resulting in duplication of effort.

Since we wanted to develop the product for a broad range of customers, we wanted to make sure that during tool initialization, OEMs would be able set up alarms, variable definitions, collection events, etc. one time for both tool control by CIMControlFramework and for the connectivity products.

With the tighter integration in CCF 3.0 to coordinate the tool control and the connectivity, initial deployment is now much easier and faster.

Below is an example that shows how alarms, events, and variables are tied together.  OEMs create the initial model using EM Developer, and then all of the configured alarms, events, variables are dynamically added to the model after startup. You don’t have to create all the details of the model, just the basic configuration and CCF fills in the data.

 Data Model resized 600

2)      Improved User Experience Through Faster Data Analysis
We learned from the initial deployments that tool operators need quick access to process data in order to improve productivity and lower costs. For CCF 3.0, Cimetrix implemented dedicated history tables to improve performance of queries on historical data.  The new history tables allow for much faster queries for wafer, EPT and Alarm history information.

All logged information is written to log files.  Any log information related to wafer, EPT, or alarm history is also written to the respective table in the on-tool database.

The benefit is fast and easy visualization of the equipment process data that is 20-30 times faster than the previous CIMControlFramework product.

The following graph shows the frequency of alarms reported by the equipment, which can be used to identify problem areas.  This type of data now comes back within a few seconds.

 Alarm History resized 600

3)      Reduce the time and effort of software installation and initial setup

The new installer allows the user to select the specific CCF modules needed and any other embedded Cimetrix products – such as CIMPortal™ or CIM300™ they want to install and configure. The installation is done in 2 phases. The first phase installs all files related to the products selected, including the source code. The second phase installs and pre-configures CCF and any pre-requisite packages. With the installation package, the time to time to install is dramatically reduced.

4)      Improved training material and code samples

To help a project team get started faster and get them more productive sooner, the Cimetrix created new labs that offer hands-on exercises.  One example is a lab to show the process for customizing user screens.  Both the problem case and the completed solution for each lab ship with CCF.  The real benefit is customers can use the labs as a starting point for their project or as reference material to help them create their own implementation.

Below is a screen shot from a lab that walks students through the process of creating a custom screen to visualize data for their specific tool, such as visualizing pressures, load locks, robots, load ports, processing chambers, etc.

UI Training resized 600

Cimetrix is a software company dedicated to continual product enhancement.  This release delivers improved functionality and performance that will benefit our customers.  With CIMControlFramework, OEMs have a great solution for tool control that allows them to spend more time and effort on delivering their unique value to the market, and far less time on tool control and connectivity—and it just keeps getting better.  This is another example of what Cimetrix does to support our customers to speed them through the development phase and into production.

Topics: Equipment Control-Software Products, Data Collection/Management, Cimetrix Products

So Much Data, So Little Time

by Dave Faulkner,
EVP, Sales & Marketing

Engineers love data. Business people love information. But it all starts with high-quality, real-time data. The possibilities are endless with good data.

As an equipment supplier, history probably has you living with a tool architecture from the early 300mm days. The focus was on implementing AMHS systems and meeting the GEM300 standards. A data driven architecture wasn't on the radar screen. And it wasn't a business priority. Times have changed. Fabs started asking for more data by creating the SEMI Interface A standards - and equipment suppliers are learning they can produce more productive equipment by leveraging the right data.

Interface A was an interesting concept when it started in the early 2000s. Discoverable data available to the fabs in real time would seem to be the answer to many problems. But the adoption has been less than stellar - even with strong endorsement and technical support by ISMI. Lack of fab side applications plumbed to use the Interface A data and "ownership" issues of the data haven't helped. These are real business problems that must be solved and will be solved with the next wave of fab purchases.

But what have we learned as equipment suppliers and software providers? Tool data models are helpful. Self description is great. We can create high performance data gathering applications that integrate with existing tool control architectures to make data available and controllable by the equipment supplier. Look at the performance of CIMPortal, our comprehensive equipment data acquisition (EDA) solution. We also learned that given the opportunity to "start over", we can create new tool control architectures that are data driven and prepared for the future. Look at CIMControlFramework. So the data is available - or you can make it available with an existing or new tool control architecture.

Let's put this data to work. Either to benefit you as the tool supplier or to help your customer. How is your tool accepted at the fabs? Do you have contingencies on your customer's payments? Does tool uptime have an impact on the tool price? Are your warranty costs too high? You get the point. With high-quality, real-time data at our fingertips, we can solve some of these business issues. We are at the beginning of a phase where the tool supplier makes use of this data and it directly impacts business results. Tool side fault detection, preventative maintenance, whatever is needed. The important point is we are finally starting from a strong foundation with the right data at the right time - and it can lead to increased margins or higher levels of customer satisfaction. Bring us your business problem and let's build something together to put this data to good use. Let's do it now!

Topics: Industry Standards, EDA/Interface A, Equipment Control-Software Products, Data Collection/Management, Cimetrix Products