Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates


CCF Provides Fully Implemented GEM300 and EDA Interfaces

Posted by Bill Grey: Distinguished Software Engineer

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.



Topics: SECS/GEM, EDA, CIMControlFramework, GEM Interface

Implementing your Process Module Using CCF

Posted by Tim Hutchison: Senior Software Engineer

Feb 9, 2017 12:30:00 PM

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!

Topics: Semiconductor Industry, CIMControlFramework, Software

EDA Testing – How is this accomplished today??

Posted by Alan Weber: Vice President, New Product Innovations

Feb 7, 2017 1:30:00 PM

Over the past several months, we have posted a number of blogs dealing with the testing of SEMI’s Equipment Data Acquisition (EDA / aka Interface A) standards suite. The first of these posts connected the importance of this topic to the increased adoption of the EDA standards across the industry, and broke the overall problem domain into its three major components. 

Subsequent postings provided additional detail in each of these areas:EDA_Icon.png

To bring this series to a close, this post addresses the “as-is” state of EDA testing as it is practiced today by the advanced semiconductor manufacturers who are requiring EDA interfaces on new equipment purchases and the suppliers who provide that equipment. 

For compliance testing, the three options in general use include: 

  1. ECCE Plus product- this software tool was originally developed under contract with the International Sematech Manufacturing Initiative (ISMI) to validate the fidelity, usability, and interoperability of early versions of the standard; it can used to manually execute a set of procedures documented in the “ISMI Equipment Data Acquisition (EDA) Evaluation Method for the July 2010 Standards Freeze Level: Version 1.0” document (see title page below) to exercise most of the capabilities called for in the standard; note that this is the only commercially available solution among the three.


  1. Company-specific test suites – one major chip manufacturer (and early adopter of EDA) maintains its own partially-automated set of compliance tests, and provides this system to its equipment suppliers as a pre-shipment test vehicle. This set of tests is then used in the fab as part of the tool acceptance process; however, this system also includes a number of company-specific automation scenarios, which are not available for outside use. This highlights the need to support custom extensions in an industry-validated tester if it is to be commercially viable.

  2. In-house custom test clients – this is a variation of #2 that some of the major OEMs have chosen as their economies of scale dictate; the problems with this approach are that a) the test clients must be kept current with the EDA standards, which are themselves a moving target, and b) unless thoroughly validated by the eventual customers of the equipment, there is no guarantee that passing these tests will satisfy the final acceptance criteria for a given factory. 

For performance and stability testing, there are no automated solutions currently available. The ISMI EDA Evaluation Method does describe some rudimentary performance evaluation procedures, but these no longer reflect the expectations of the customers with many years of accumulated EDA production experience. Clearly a better solution is needed.

Finally, for metadata model conformance testing, the only available solution is the Metadata Conformance Analyzer (MCA) that was commissioned by Sematech and implemented by NIST (National Institute of Standards and Technology). It has not been updated in almost five years, and exhibits a number of known issues when applied to a SEMI E164-compliant equipment model (E164 = Specification for EDA Common Metadata), so it will be increasingly insufficient as more companies require full Freeze II / E164 specification compliance. 

The good news in all this is that Cimetrix has recognized and anticipated this emerging need, and is actively addressing it on our product roadmap. If you want to know more about EDA testing and/or discuss your specific needs, please contact Cimetrix for a demonstration of this exciting new capability!

Topics: Interface A, EDA, EDAConnect, ECCE, Data

President's Letter to our Cimetrix Community

Posted by Robert H. Reback: President and Chief Executive Officer

Feb 2, 2017 11:30:00 AM

To the Cimetrix community of clients, partners, shareholders and employees,

Cimetrix had another year of solid progress during 2016. Financial results were in-line with expectations, as Cimetrix continued to achieve profitability every quarter with full-year revenue in the $6M to $7M range.

Our key highlights include:

  • Cimetrix continued to enhance its reputation for product quality and the highest levels of customer support in the industry, receiving consistently excellent feedback from our client base.

  • Cimetrix continued to invest in building great products with new releases of all our product lines. Substantial improvements were made in both new features and internal testing that will benefit our clients for many years. 

  • Cimetrix gained additional “design wins” for its products in North America, Europe and Japan, where the company has an established presence. In addition, Cimetrix won important new clients in China and Korea. 

  • Cimetrix strengthened its organization as we added a number of new employees in business development, software engineering and technical support functions. The Company continued to invest in employee development, education and continuous improvement. We believe the concepts and training we’ve received in lean and agile processes will enable Cimetrix to build better products and more efficiently provide our clients with the highest levels of service. 

  • Cimetrix made a number of key investments that we believe will lead to future long-term growth. We strengthened our local sales and technical support in a number of Asian countries. We developed a number of new product prototypes in collaboration with key clients leading to the introduction of an exciting new Cimetrix product in 2016. Several other new products are in development and have the potential to significantly expand our markets.

Cimetrix also held its first shareholder meeting since going private in late 2014, which provided a forum to explain to shareholders why the Company took that important step, the progress we’ve made since going private, and our future plans. As a result of generating positive cash flow from operations, Cimetrix was able to continue providing liquidity for shareholders that contacted the Company. Prior to going private, the Company had over 4.5M shares outstanding, adjusted for stock splits. As of December 31, 2016, the Company had fewer than 3.9M shares outstanding. This means that every current shareholder’s ownership percentage has increased by over 15%.

Going Forward

Going forward, industry analysts predict an increase in semiconductor capital equipment spending for 2017. In addition, we are seeing increased traction for the relatively new SEMI Standards for Equipment Data Acquisition (EDA), also known as Interface A. We believe these trends will enable us to achieve short-term incremental increases in revenue that support continued operations on a profitable basis and investments in new products and markets that will lead to longer-term step function increases in revenue.

We will continue to focus on satisfying our worldwide base of clients, improving our efficiencies and effectiveness, and executing our plan to expand the markets for Cimetrix products for long-term growth.

From all of us at Cimetrix, we thank our clients for the trust they have placed in our products and our team. We also thank our shareholders for their patience and support. 


Robert H. Reback
President and Chief Executive Officer

Topics: Partners, Doing Business with Cimetrix, Working at Cimetrix, Cimetrix Culture, Announcements, Investor News

14th Innovations Forum for Automation

Posted by David P. Faulkner: Executive Vice President, Sales and Marketing

Jan 31, 2017 11:04:00 AM

The 14th innovations forum for automation was held on January 19 and 20, 2017 at the DGUV Akademie in Dresden, Germany.

14-Innovations-forum-snow.jpgCimetrix was one of the sponsors of the conference.  Dresden is hot bed for semiconductor manufacturing in Europe.  In fact, 50% of the chip output from Europe comes from Dresden. The conference is organized by the Automation Network Dresden which consists of 5 Dresden based companies; AIS, HAP, Ortner, SYSTEMA and Xenon.  SYSTEMA is a Cimetrix partner and helps us with integration projects. 

The focus of the conference is to bring the latest information on best practices, new technologies and the future of automation.  Themes this year were Smart Manufacturing, Industry 4.0 and IIOT (Industrial Internet of Things).  Presentations by Bosch about their automation roadmap, Infineon about running experiments in a highly automated fab, Kostal about standardizing MES, and IAV about the challenges of automated driving where a few of the interesting case studies and technologies.  This is a great conference to meet semiconductor professionals from Europe and learn what the European community is doing in the area of fab automation. For Cimetrix, it is good to see that equipment to host connectivity plays a key role in all the projects outlined during the conference. Sponsoring and attending gave us the opportunity to meet with current customers and start discussions with new potential customers. 


Before the conference, SYSTEMA held an Expert Day session at the SYSTEMA facility in Dresden on the morning of January 19.  The session was a series of presentations targeting predictive maintenance.  SYSTEMA and its partners have a wealth of experience in this area.  



Topics: SEMI, Events, Germany

Cimetrix HostConnect

Posted by Joe Cravotta, Client Support Engineer

Jan 26, 2017 11:45:00 AM

Cimetrix is proud to release its first new product to assist in GEM host application development, and I’m excited about how this is going to change the development of new host applications. Prior to the release, I was given access to HostConnect, a native .NET software development kit, and used it to create a couple of applications that connect to GEM equipment.

In developing those applications, I quickly became familiar with the layered architecture of HostConnect. HostConnect has four layers; each layer name and relevant classes is shown in the image below.


As with most layered objects, each additional layer adds to the previous layer. Now that I’m familiar with these layers, starting with the first layer, these are the aspects that stand out to me:

  • SECS Messaging: This is equivalent to our SECSConnect product. A solid understanding of the SEMI E5 (SECS-II) and E30 (GEM) standards is necessary to interact with this layer. The user application must be able to construct, parse, and handle asynchronous SECS-II messages.

  • SECS Transactions: This layer adds classes (generically called SxFy classes) to abstract the construction and parsing of many SECS-II messages. It also has the ability to synchronously send and receive SECS-II messages. Automatic message replies may be configured, but none are setup by default.

  • GEM Capabilities: This layer specializes the SECS Transaction layer for use in GEM host applications by setting up common automatic message replies and providing the EquipmentCapability classes (more detail about these classes below).

  • Connection and Discovery: This is the layer I’m most excited about because it is configuration based. The discover feature quickly characterizes an equipment’s GEM interface for HostConnect to use.

After working with HostConnect, I’m reminded of the task that got me acquainted with the SEMI E5 and E30 standards. I was asked to create a GEM host sample application from scratch. A large majority of my time was spent learning specific SECS-II messages and understanding the capabilities defined by GEM. After a few months, the sample application included trace report, collection report, and unformatted recipe management. If HostConnect was available, I’m willing to say I would have been able to complete this task in only a couple of weeks.

Remember the EquipmentCapability classes I mentioned? These classes encapsulate common GEM capabilities, and is one reason I believe I would have been able to complete the sample application in a much shorter time. For example, the EventReports class greatly simplifies report management. Simply register for the EventReportReceived event to receive incoming report data. The report data is parsed and provided in an easy to use parameters object. You don’t need to parse the SECS-II messages, and you don’t even need to know which SECS-II messages are used.

Another reason HostConnect would simplify my sample application, and the most exciting feature to me, is the configuration ability at the fourth layer. HostConnect stores default behavior options and an equipment’s GEM interface within a single configuration file. The discover feature can characterize an equipment’s GEM interface and create the configuration file for you. With a single file per equipment, it would be simple for my sample application to communicate with several different equipment without any code modifications. This flexibility makes HostConnect ideal for developing an application that needs to communicate with multiple different equipment, such as a testing application.

Seeing how much HostConnect does out of the box, but also allowing customization by accessing lower layers, I can say that I wish I had HostConnect when I built my sample host application.

Topics: Announcements, HostConnect

Designing Recipes in CCF

Posted by Derek Lindsey: Product Manager

Jan 24, 2017 11:00:00 AM

Anyone above a certain age will be able to tell you what you get when you combine two all-beef patties, special sauce, lettuce, cheese, pickles, onions – on a sesame seed bun. There are many who would argue that what sets a Big Mac apart from other burgers – and has made it one of the best-selling products of all time – is the special sauce.

In a March 2016 blog post, 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 provide process and path information through the tool using recipes. This blog post delves a little deeper into the recipe aspect of equipment control applications.

In CCF, recipes are either process recipes or sequence recipes.


A process recipe contains the instructions to be carried out by a particular process module. These instructions can range from temperature settings to types of gas to flow. The most important aspect of any tool control application is allowing the tool manufacturer to do what they do best – perform their process better than anyone else in the world. The process recipe allows tool manufacturers to add their special sauce to the wafer. CCF provides a sample process recipe implementation as well as very simple process recipe editor. Since recipes are generally custom for each tool manufacturer, CCF application developers usually want to customize the recipe contents for a process recipe.

If the processing of material is the special sauce, the rest of the application, moving the wafer through the tool, is a necessary evil. To assist in moving material through the tool, CCF also provides a sequence recipe. A sequence recipe determines which process recipes are to be run, at which modules to run them, and the order in which this is to occur. CCF provides a sample sequence recipe editor that can be used in creating sequence recipes or customized for each tool manufacturer’s needs.

Both process and sequence recipes can be created on the tool or downloaded from a factory host. CCF provides a handler that receives recipes from the host and stores them in the Recipe Server. Regardless of where the recipes are created, CCF’s Recipe Server stores the recipes locally and passes them in to the scheduler when a job is to be run. The Recipe Server allows recipes to be stored as Engineering recipes while they are being finalized. They can then be promoted to Production recipes for use in a production environment. 

By making use of recipes in CCF, you can ensure that your special sauce is applied to material processing to help make your tool one of the best-selling in history.


Topics: CIMControlFramework

Fall 2016 SEMI Standards Meeting

Posted by Brian Rubow: Director of Client Training and Support

Jan 18, 2017 11:30:00 AM

SEMI_logo_share.jpg SEMI North America Information & Control Task Force and Committee fall meetings were last held at SEMI headquarters November 7 through 9, 2016. During these meetings, SEMI announced that they are relocating their headquarters to Milpitas, CA. That move is currently underway. In the GEM 300 task force, all of the ballots failed to pass. This include ballot 5872A, 5549, 6026, 6066, and 6068. In the DDA task force, ballot 6064 also failed.

Ballot 5872A is work driven by Cimetrix to complete to work initially proposed for the E172 standard SEDD files, a feature to enable an electronic format for GEM documentation. Ballot 5872A failed due to some minor issues. SEDD files already provide partial GEM interface documentation in an XML file by listing the data variables, status variables, equipment constants, collection events and alarms. The ballot proposes to enhance SEDD files by adding a list of supported SECS-II messages, remote commands, SEMI standards (with compliance tables), and default event reports. The ballot will be reworked and resubmitted as ballot 5872B.

 Ballot 5549A is a title change and organizational change to the GEM E30 standard. Several years ago, SEMI required all standards to have an official designation, such as Guide or Specification. E30 currently has a title that fails to establish an official standard designation. Additionally, the standard currently fails to have the mandatory sections “Purpose”, “Scope”, “Limitations” like other standards. The ballot was delayed several years due to the SML copyright claim by Peer Group and the ensuing legal confrontation with SEMI. The ballot was finally submitted in 2016 and failed because it renamed the Application Notes as an Appendix instead of “Related Information”. Additionally, there was some confusion because the ballot was based on the 0611 version of E30 rather than the 0416 version which had just been published. This ballot will be reworked and resubmitted as ballot 5549B.

 Ballots 6026, 6066, 6068 and 6024 are reapproval ballots for standards E109, E130/E130.1, E116/E116.1 and E121. SEMI automatically submits all standards for re-approval every five years if a standard has not been revised. These standards all failed due to outdated references. They will all be resubmitted in 2017 with minor changes to correct the outdated references.

 The new GUI task force was approved to create a new major revision of the E95 standard. In particular, the new revision will accommodate new software and hardware technology when laying out equipment user interfaces.

 Cimetrix proposed a new activity to define new SECS-II messages for transferring recipes. The activity will result in a new ballot 6614. Currently, the GEM standard defines two ways to transfer unformatted recipes. Using simple Stream 7 messages S7F3 and S7F6, the entire recipe is part of a single message. This makes is really easy to implement in the host and equipment GEM software, but recipes are limited to about 16.7 MB (the maximum size of a single data item in any SECS-II message). The second way is using the large recipe scenarios which involve using a sequence of messages S7F43/F44, S13F1/S13F2, S13F3/F4, S13F5/F6 (repeated iteratively until there is an error), S6F11/F12 and finally S13F7/F8. Even for an expert, this is very complicated. Ballot 6614 will propose simple new messages for transferring a large recipe using a single message where the recipe can be broken up into multiple parts where each part is up to 16.7 MB in size. If approved, another ballot will attempt to add this to GEM standard. This will open the door for the GEM standard to be used more effectively and in more application where the 16.7 MB limitation posed an issue.

 Japan Information & Control committee (I&CC) announced the official withdrawal of OBEM standards E98 and E98.1. Japan also announced a GEM300A initiative which includes standards E170 and E171 and E174. E170 is the Production Recipe Standard which allows equipment to designate production and non-production recipes; where production recipes are given change protection. E171 defines predictive carrier logistics. Ballot 5601 defines Wafer Job Management. It is not clear whether or not there any IC makers will demand any of these newer standards. Of the three, E170 seems to be most useful and interesting. Predictive carrier logistics seems to be useful only for equipment that have carrier internal buffers. It attempts to help the equipment report when carriers will be ready for removal. It is not clear how E171 will compete with the upcoming E87 ballot 4946 to be submitted by the Korean Information & Control Committee in 2017. Ballot 4946 modified the E87 standard to predict when carriers will be ready to unload. Wafer Job Management is a controversial standard. Japan I&CC announced the passing of ballot 5601 (now E174) despite the strong opposition by multiple knowledgeable voters in other regions, and despite very underwhelming support from regional leaders in North America, Korea, Europe and Taiwan.

 Korean Information & Control committee announced plans to submit ballot 5832, a proposal for a new Generic Counter standard which is built upon the GEM standard. The standard would allow an equipment to define various types of generic “counters” that can be reset by the host. The counters could be used a wide variety of applications; particularly predictive maintenance. The standard as defined in the current ballot defines digital counters, analog counters and collection event counters. Voting period for this ballot just ended recently.

 Next North American I&CC meetings will be held first week in April, 2017.

Topics: SEMI Standards, Semiconductor Industry, SEMI

Create Operator Interface Screens Using CCF

Posted by Harley Pebley, Software Craftsman

Jan 5, 2017 1:31:00 PM

Our bodies are amazing machines. Ask a man off the street what they see when they look at someone, they will probably talk about skin, hair and eye color, height and weight and other external defining characteristics. Ask a doctor and they may see issues relating to what’s going on in the person’s organs and overall internal function. Ask a molecular biologist and they’ll talk about the chemical pathways that allow things to work at the cellular level. Much like our bodies, computer controlled systems are made up of many layers. Starting with electrons moving through conductive and semi-conductive materials, abstraction layer is added upon abstraction layer to create components, circuits, assemblies until finally a computer is created. In the same way layers of software control this computer from the BIOS up through layers in the operating systems and culminating in the application the user sees. Similar to the way doctors and biologists work at different levels of abstraction within their domains, we as engineers know about, work with and think about our system at various abstraction levels. However, the end user is like that man on the street, all they see are the external characteristics. Because of this, the operator interface is among the most important parts of the system.

SEMI established the E95 standard as general guidelines for screen layout of tool control software. CIMControlFramework (CCF) provides a standards conforming shell into which various screens may be added to create a complete operator interface. This allows the tool manufacturer to focus on the unique needs of their tool and have no worry about meeting the standard.

There are several general steps to create an operator interface using CCF:

  1. Decide on the technology. In the Windows desktop software world, there are two primary ways of developing a user interface: WinForms and Windows Presentation Foundation (WPF). CCF has historically supported the WinForms environment providing many fully functional WinForms screens. It has also supported WPF, but only provided a single example WPF screen. Cimetrix is in the process of updating WPF support and adding multiple fully functional WPF screens out of the box. Either environment may be used based on what the tool manufacturer’s developers deem appropriate.

  2. Establish the requirements. The purpose of the operator interface is for the tool to provide the operator with information about what it’s currently doing and for the operator to tell the tool what to do. Determining the correct way to do this can be one of the hardest parts of designing a user interface. This step is where the best level of abstraction is established. The user should have sufficient information to understand what’s happening without being overwhelmed by too much data. The user should also have enough control to do what needs to be done without having to worry about too many details. The analysis for this step is often done by multi-disciplinary teams using analog methods like whiteboards and pen and paper. Creating avatars for different types of users and then writing stories about what those users will want to do is a good way to help flesh out what’s needed by the operator interface.

  3. Evaluate pre-built screens against the requirements. Once the target is established, the screens provided by CCF can be examined for fitness. How well do they fit the target? Some screens may be close enough to the requirements to be used as is. Other screens may be close but require some tweaks to meet the specific needs. Finally, some screens may need to be built from components provided by CCF to satisfy the unique specifications of a particular tool.

  4. Assemble the screens into an application. Once a list of needed screens is created, the final step is to put everything together. This is generally the most time consuming part of building an operator interface. This phase is when any custom screens are built or modifications made to existing screens. Finally, all the screens, both custom and pre-built, are added to the framework provided by CCF. CCF has a number of labs to help understand how the various user interface components work together to provide a cohesive whole.

CCF provides the structure, pre-built screens and tools to assist in creating custom ones to give your tool a beautiful skin.

Topics: CIMControlFramework

Create a Scheduler Using CCF

Posted by Derek Lindsey: Product Manager

Dec 14, 2016 11:30:00 AM


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.


Topics: CIMControlFramework

Receive Email Updates

Follow Us

Learn More About the
SEMI Standards


GEM 300

Interface A/EDA