Do you need to develop complex drivers for the components in your equipment? Let’s see how the CIMControlFrameworkTM Communicator Framework helps you accomplish this.
What is the CCF Communicator Framework?
The Communicator Framework simplifies the low-level message handling to and from the hardware by encapsulating the connection between CCF and the device.
As an example, consider how the connection is made between control software and hardware devices. An ASCII serial connection needs a socket connection using TCP, a multi-threaded mechanism to handle multiple messages to/from the devices, logic to synchronize the commands and their respective responses, and several other functions. This is a lot of work when developed from scratch.
As an alternative, CCF provides a built-in ASCII serial connection class to achieve all these quickly. You can simply use this class to create an ASCII serial connection to the component.
What is the specific role of the Communicator Framework?
Each component or device in an equipment provides a set of commands and responses to perform its designated function. The Communicator Framework includes a Transaction class that handles these commands; each command to a particular device is implemented as a transaction.
Consider the case of the Clamp activity for a loadport—the associated command could be “LOCK.” Now let’s see what are our tasks are to implement this command in a loadport driver as a CCF developer.
The first step is to create a Transaction class for the loadport which must be inherited from the base CCF Transaction class. See below for an example that creates the “Clamp” transaction.
In this example, the ClampTransaction class accepts the command Clamp as an attribute. The command which is passed as the attribute to its base class will be sent to the device through the ACSII serial connection.
The next step is to implement a Communicator class to send the command and receive responses from the device. See the sample code below.
The CCF product includes a LoadPort class. Here we initialize the Communicator class with the ASCII serial connection to perform the transaction.
When a clamp activity is needed, CCF calls the Clamp function of the LoadPort to do the clamping. We use the Communicator object just initialized to send the command to the hardware. Note that we did NOT write any code for sending the command or receiving its response because this is the job of the Communicator. You send the command to the hardware by calling the PerformTransaction function of the Communicator base class as shown below.
Believe it or not… that’s it! We sent a command to the device with very few lines of code in the driver. Now, how do you handle responses from the device? Let’s have a look.
Each device implements different responses to the command set, depending on the manufacturer of that device. This may include acknowledgments, data items, events of various types, and so on. So, whenever the Communicator receives a response from the device, it calls an abstract method on a child class to parse the response. As a CCF developer you must decide what type of response it is, whether or not it successfully completes the transaction, and how to respond to the Communicator as a result.
The example below shows how to parse a response from the device.
Finally, how can we deal with the events from the hardware? From the code above you can see how to indicate that the type of response is an Event, and in this case, it will invoke another abstract method on its child class to handle the event. The CCF developer can then handle it in their code as shown below.
That’s all there is to it. The code segments above provide an example of a basic loadport driver that includes a Clamp transaction. To implement additional commands for your device, simply add more transactions and call them from the equipment controller. The Communicator Framework will handle the rest of the communication with your device.
To learn more about CCF or other Cimetrix products, click the link below:
