A simple case study

There are applications that are suited for PC based controls, and others that aren’t.  When a control application can be easily handled by a small PLC system, there is usually not a compelling reason not to go that route.  Sometimes PLC based systems start to grow in directions that make it compelling to want a PC in the system.

Lets take the example of a simple leak test system.  Our customer wants a system to leak test an automotive exhaust system.  Since the allowable leakage is relatively high, the customer decides to go with a simple system that uses some pneumatic cylinders to clamp the part in a nest, and some more cylinders to plug the openings in the part.  Then air will be introduced to the part at a crudely controlled rate for some duration of time.  There will be a pressure switch to sense the air pressure in the exhaust system.  If the pressure switch closes in the allotted time, the part will be considered good.  If the part is good, it will unclamp, and a green light will come on.

This system can clearly be controlled with a simple PLC.  There is no compelling reason to consider a PC as the control system for the above specification.

Let’s consider the same system, with different requirements.  The end customer of the exhaust systems decides that the leakage must be much lower than originally specified.  This change requires more care in doing the leak test, so our customer decides to go with a commercial leak tester.  The end user also decides to track the parts by serial number, and they want the leak data stored by serial number and laser marked on the part.  The data must be transferred to their information system computers, and forwarded to the end user.

So, our simple system has expanded.  We now have to use a barcode reader to read the serial number of the part, which has a barcode label on it.  We have to perform the test, and get the results from the leak tester.  The data must be sent to a laser marking system that will etch it onto the part.  The data will also be stored in a local database, and transferred to the network.

The barcode reader has a serial port as the interface.  The leak tester also has a serial port that can be used to issue commands, and collect data.  The laser marker has a USB interface.  The factory network is standard Ethernet.

Suddenly, this system has migrated into something that includes a number of requirements that are not so easily implemented in a simple PLC system.  The system has become more data-centric, and less control-centric.

Given the expanded scope, we now have to make a choice.  Do we beef up the PLC system, adding the appropriate communication ports to handle the new requirements, or do we incorporate a PC in the system, and have it handle the minimal I/O requirements to do the things that the PLC would have done in the original system?

Another feasible choice is to leave a simple PLC in the system to handle the I/O, and add a PC to the system to handle all of the communication and data requirements.  This solution is fairly easily implemented.  Ironically, the worse part of this solution is often the communication between the PLC and the PC.  The PC can usually talk to the other devices rather easily.  (This is because PLC communication interfaces are usually proprietary protocols, and the other devices commonly use simple ascii strings to communicate.)

The upshot is, systems that are relatively simple can grow into systems that are not easily done with simple PLC controls.  In those cases, PC based controls are worth consideration.