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.