Industry News, Trends and Technology, and Standards Updates

Hi folks! We in the CCF (CIMControlFramework) Services Team love training/consulting on CCF implementations and building custom software for our customers. We’re especially thrilled when we can help our customers ship new equipment and subsequently hear that the equipment successfully ran thousands millions of cycles without issues.

Recently, we enjoyed helping one of our customers build a tool that processes non-wafer substrates. The tool control system included some typical components such as Rorze Hardware Drivers, Light Tower drivers, and a Load Port E84 IO Control, but had some more unique capabilities as well. In this posting we will explore some of the challenges posed and advantages realized from these special capabilities. Before we dive in, please allow me to give a shout out to John Last, our Senior Software Engineer who designed and built most of these capabilities.

Process Module Operation Screen

Rather than simply logging data points, our customer wanted a visual representation of temperature over time (minutes). We displayed the categorized variables and their values in tables as well, but the graph updating in real time made it much easier for the operator to visualize the patterns and identify risk events and their sources. The graphing feature needed to be active whether or not the process module operation screen was being displayed. Moreover, It had to handle 3 different step types (Ramp, Dwell and Cool).

Calculating the Y-Axis range for this display presented an additional interesting challenge. The minimum and maximum values were determined by searching all recipe steps and selecting the lowest and highest value setpoints, then subtracting a fixed number from the lowest to get the Y-Axis minimum value and adding a fixed number to the highest value to get the Y-Axis maximum value. The figure below shows how the expected process data should look compared to the observed process data. This allows the operator to see what the equipment is expected to do compared with its actual behavior.

Partial FOUP grouping to create a single batch

Our customer required the capability to group multiple partial FOUPs into a single batch. This is especially useful in scenarios where partially filled FOUPs would be used—say, in R&D environments. In other words, we needed to support scenarios where the number of FOUPs needed for processing a batch exceeded the number of load ports. This required us to create Control Jobs with a MtrlOutSpec containing a valid SourceMap with an empty DestinationMap. We relied on SEMI E94’s concept of “Late Announcement of Output FOUP” to specify the input FOUP but not the output FOUP. This allows the scheduler to say, “We know the substrate will go to a different slot, but we won’t tell you which slot until later.”

E90 substrate reading in the Panel solution

As with most tools, each of the substrates has an ID, and this ID must be read and reported to the host. In this case, our host had to verify that the expected ID matched the actual ID. On a successful match, the equipment would then continue the job. If it failed, however, the host would be notified and decide whether to proceed or change something. Capabilities like these maximize throughput and mitigate risks to equipment safety side and production scrap.

Different Panel Types

This machine was required to deal with panels having multiple thicknesses and possible warpage. Therefore we needed to provide a method for an operator, the recipe, and the host to specify the panel type to be processed. None of the variations of panel types were known ahead of time, so we needed methods that handled additional panel types without having to make code changes after the equipment was deployed in production.

The tool also required different substrate mapping parameters for each panel type. Because panel type was specified in the process program referenced in the Process Job, the panel type was not known when the FOUP arrived at the load port. To handle this situation, we customized a standard factory automation SECS II message to communicate the panel type from the host to the tool on arrival of the FOUP.

Conclusion

This equipment was built on an extremely aggressive timeline by a very small team. I was particularly impressed by the team’s ability to grasp the end customer’s requests and creatively explore alternative ways to solve the never-before-seen challenges. In summary: no drama; a few delays; even fewer verbal altercations; just a little frustration; only a little scope creep; and most important, a satisfied factory customer. We all cheered when our customer shipped the tool in 2020.

To find out more about CIMControlFramework and our CCF Services team, or to contact us for a demo, click the button below.

Welcome to the first posting in the Cimetrix CIMControlFramework (CCF) Services blog series! While Cimetrix has been providing professional services for many years, in order to better serve the growing demand from many new equipment maker customers worldwide that have purchased our CCF product, Cimetrix earlier this year formed a new CCF Services group, reporting directly to the CEO. Being a senior developer at Cimetrix for the past 15 years in a variety of positions, I was delighted when asked to lead this group. We have an outstanding team of software engineers highly experienced in factory automation, equipment control software and SEMI standards. We are dedicated to ensuring our customers’ success by providing training, consulting, and developing custom solutions for our CCF customers. We love learning about the myriad ways that companies can integrate CCF with their equipment to meet the material handling and factory automation requirements of their factory customers. Our goal for these articles is to share some of the lessons learned and other implementation insights to help you efficiently build manufacturing equipment that is sophisticated, robust, and productive. To this end, our first posting will deal with one of the most common requests we get – enjoy!

- Forward by Brent Forsgren, Director of CCF Services

How we helped a customer deliver a GEM-compliant equipment using CCF

The Goal

One of our recent customers wanted to build a new type of LED manufacturing equipment that could be controlled by a Factory Host using the standard GEM Remote Commands: PP_SELECT (Process Program Select), START, STOP, ABORT, PAUSE and RESUME. The equipment could be delivered in a variety of physical configurations, including 1-to-multiple source cassettes for product material, and 1-to-multiple process modules. It also had multiple destination cassettes to be filled according to the post-process analysis results. The initial instance of the equipment had 4 loadports (LPs) and four process modules (PMs).

The functional requirements were clear – that was the good news. Now for the rest of the story… the project schedule and budget constraints were closing in, so we needed to work quickly and efficiently with the customer to get it done. Sound familiar?

The Approach

The Cimetrix CCF Services team always works closely with the software team of the equipment manufacturer. In this case, we started with one week of mutual discovery and in-depth hands-on training. Team members were fully engaged and picked up the CCF capabilities very quickly. This included even some of the more advanced features, such as developing a scheduler that would control the components of the customer’s application. We regularly fine tune training modules to 1) introduce CCF concepts, 2) expose common challenges and potential approaches, and 3) provide realistic implementation practice exercises. As anticipated, the customer was able to use the results of the training exercises in the actual equipment control solution. We also kicked off the project with our work-breakdown exercise to more deeply explore the unique requirements for their specific equipment type.

After an intense first week, everyone on the project team concluded that CCF would in fact be a strong match for their needs. CCF features direct integration with our CIMConnect, CIM300, and CIMPortal connectivity products to provide full GEM, GEM300 and EDA compliance. Because the Cimetrix connectivity products are deployed in every semiconductor 300mm factory in the world, our customers can be assured that they will meet their customer’s factory automation requirements. In this application, the end customer’s LED factory only required GEM.

To address requirements that may go beyond the basic GEM standards, CCF also provides support for custom remote commands, data publication, and alarm management. Finally, CCF supports integrating custom hardware devices using CCF’s base Equipment Classes.

To prove all was working, we chose the Cimetrix EquipmentTest product to develop and execute a set of unit tests that emulate communications with the factory software using GEM messages. This was not intended to be a comprehensive set, but rather just enough to show the equipment passed round-trip system testing. In this context, round trip means showing that the equipment can move material from the incoming cassette to the aligner to the process module and back into the cassette. EquipmentTest also supports editing message settings and parameters on the fly to experiment with different configurations of a round-trip test.

The Challenge: “The Host is unavailable, but we need to validate that the equipment is both GEM compliant and accomplishes the communication flows the end user requires.”

We get this challenge a lot… Our customers almost always develop the host interface and the embedded control software in parallel and integrate them later in the project. This makes sense at one level, but it does introduce a “chicken and egg” problem for testing this kind of GEM interface. In particular, how can our customer provide evidence that the solution will work with the factory host without testing with the actual host system? Our answer: apply our EquipmentTest custom plugin capability to simulate the end user’s host so we can validate all necessary communication between host and equipment.

Our protocol validation product, EquipmentTest, makes it possible to simulate communications between an equipment control implementation and the host. And although it is impractical to implement scenarios for every possible interaction, we can create enough representative scenarios to be confident the “happy path” (i.e., no errors) will work and that the interface will handle a large handful of “sad path” cases as well.

Outcome

We passed all the tests! “Let’s go get some tacos.”

Specifically, we validated that the communications interface supported…

• Standard GEM Remote Commands
• Custom Remote Commands
• Material tracking
• Data publication

In closing, we must emphasize that our customer should take most of the credit here. Nevertheless, we enjoyed observing, consulting, and testing the equipment. It is always gratifying to see the CCF solution fit so seamlessly into the hardware, execute its commands with optimal timing, and not break anything in the process! Truly a successful, joint team effort.

If the situation above resonates with your current challenges and past experiences, give us a call. We look forward to working with your software engineering team to speed your time-to-market and deliver a high-quality solution quickly, allowing your team members to focus on developing value-added functionality for your customers.