Things are the way they are because they got that way…

I’ve mentioned previously that our systems here at TAF interact with programmable logic controllers (PLCs). This has always added some interesting challenges to our testing. PLCs are designed to interface with physical devices such as torque wrenches and electrical switches, but not so much with other computers. Here’s a fairly typical interaction that occurs on the assembly line:

When a transportation appliance reaches a certain point on the assembly line, it triggers the read of an RFID tag travelling with the appliance. The value of this tag is stored in a memory location in the PLC. Our client program is notified when this occurs so it can react appropriately. Let’s say the appliance has reached the point where a wheel needs to be installed. Depending on the appliance, it might be a steel or alloy wheel, which have different tightening, or torque, requirements for the bolts holding on the wheel. Our client, therefore, has to look at the identifier value, determine what kind of wheel is required for that appliance, and write the torque requirements to the PLC to program the torque wrench appropriately for the wheel type. The wheel is installed on the appliance and the bolts are tightened down. The torque wrench will record the value of force actually applied to each bolt to a sequence of memory locations in the PLC, and, when all the bolts are tightened, the client program is notified that the operation is complete. The client program will then read the torque values and record them to a database entry, tying the appliance identifier with those values for all of posterity.

By itself, the PLC doesn’t know how to talk to our client program. It just knows enough to read and write values in various memory locations. At TAF, we have a Java-based server that reads from and writes to the PLC memory. It reads information about a PLC’s configuration from an XML file, including the device type, which is used to load an appropriate driver, and how the PLC’s memory is to be mapped, including which memory locations are to be broadcast if their value changes. The Java server will use this to publish update notifications and such.

Speaking to the Java server is Smalltalk server. Our client programs connect to the Smalltalk server and register interest in event notifications from the PLC. When a memory location within the PLC changes value, the Java server notifies the Smalltalk server, which then broadcasts the updated information to all registered clients. Should a client not respond in a reasonable time, it is assumed to be dead and dropped from future notifications. The Smalltalk server communicates with the Java server using fairly straight-forward TCP/IP sockets, pushing XML-based messages back and forth over the wire. Our client programs speak to the Smalltalk server using a pre-cursor to the current generation of VA Smalltalk’s Server Smalltalk Distributed Objects (TAF’s systems were written before Server Smalltalk was available). Going the other way, the client program will tell the Smalltalk server that a particular memory location is to be updated. The Smalltalk server in turn tells the Java server, which finally writes the value to the PLC.

It may seem like an inordinately complex system, but it works. The system was developed for TAF by a third-party company to replace an obsolete system originally provided by IBM and has performed well for a number of years now. The intention was to minimize the impact on the rest of the code base, and, in that, the system was also a success. However, for supporting development and testing of Smalltalk clients, it has proven lacking.

The original authors provided a mechanism to read XML scripts into Java to simulate the update of memory locations in a PLC, but this isn’t useful for determining if a Smalltalk client is correctly reacting to changes in PLC state. Nor is XML exactly a friendly language for scripting anyway. Matters were brought to a head when I was given the assignment of developing a new client that relied on reading and writing to over a hundred memory locations in a PLC.  Another approach was definitely needed!

Advertisements

0 Responses to “Things are the way they are because they got that way…”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: