Industry News, Trends and Technology, and Standards Updates

Derek Lindsey: Product Manager

Derek Lindsey has been an employee of Cimetrix for over 22 years. For 21 of those years, Derek was a member of the product development team and was involved in the development of several of Cimetrix products. He also has extensive experience working with Cimetrix customers in implementing their tool control solutions using our products. He recently joined the product management team to help add some technical expertise to product development. Derek has a bachelor’s in computer science from Brigham Young University.
Find me on:

Recent Posts

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

Software Interfaces and API Method Signatures Should Remain Consistent During a Product's Lifecycle

Posted by Derek Lindsey: Product Manager on Jan 28, 2016 1:07:00 PM

TheMartian.jpg

I recently read The Martian by Andy Weir. Since this information comes out on the first page of the book, I don’t think I’m spoiling too much to say that it is the story of an astronaut, Mark Watney, who is lost in a space storm on a mission to Mars. He is presumed dead by his crewmates and abandoned on the planet. Of course he is not dead and he has to use training, skill, ingenuity, and luck to survive long enough to be rescued. Several times throughout the adventure, he has to connect life supporting utilities, tanks, airlocks, and vehicles together using the connecting valves supplied on each component. Watney says, “I’ve said this many times before, but: Hurray for standardized valve systems!” This is obviously a work of fiction, but what would have happened if he had tried to attach a holding tank to the ascent vehicle but the valves had changed between versions?

Software customers should be able to have the same expectation as Mark Watney that the valves don’t change during the mission. In the case of software, we aren’t talking about physical valves. Rather we are talking about software interfaces and API method signatures. In a real sense, the consistency of these software signatures are as mission critical as the standardized valve connections were for the astronaut in The Martian. Changing the method signatures, at the very least, requires that the users of the software have to rebuild their applications. Often times such changes require software users to have to requalify their entire tool. This places undue burden on the users of the software. Software users should be able to reasonably expect that the interfaces and API remain constant through the life of the mission (i.e. within the version of the software including minor releases and patches). A side note on this topic: If Cimetrix product management determines that a piece of software has a bug or does not conform to the SEMI standards on which our products are based, changes will be made to correct the problem. Similarly, if NASA determined that one of their connectors did not conform to the spec, they would immediately resolve the issue for the item that was out of spec.

The Cimetrix release versioning process (see our January 14, 2016 blog) allows Cimetrix personnel and Cimetrix software users to be aware of what backward compatibility guarantees are made for a specific version of Cimetrix software.

We would like our software users to be able to say, “Hurray for compatible software versions!”

Topics: Semiconductor Industry, Doing Business with Cimetrix, Cimetrix Products