FAQ: Is a PLC fast enough to meet my application’s requirements?

Knowing if your PLC is fast enough and can handle your application is really a two-part process. That is, it can be looked at from two different but intertwined perspectives; one is from the PLC perspective and the other is from the application level.

The most important factors are knowing the specifics of the application as well as the specifications and capabilities of the PLC. Keeping both perspectives in mind should provide a firm understanding of the problem and should lead to selecting the right PLC for the job.

From the PLC perspective, the important questions come down to specifications such as memory, scan rate, and I/O.

Memory: Like a computer, the more memory a device has, the more it’s able to handle. It can execute tasks faster and ultimately perform better. On the other hand, a PLC with limited memory will run slower.

Scan rate: All PLCs have a basic scan rate, which is the rate at which they scan the inputs, process data by running through the control program, and update the outputs. Obviously, the faster the scan rate, the faster the processing and update time. Also, the fewer inputs there are, the shorter the program is, and the less outputs to update, the faster it will generally execute.

I/O: This is important for obvious reasons as well. Fewer inputs to scan and fewer outputs to update means faster operation. As the number of inputs and outputs go up, so does the time required to scan them all and run through the PLC program.

Software: Another issue is software. There may be conflicts with different software packages, memory getting overloaded, or old legacy software that slows down the processing time.

This diagram shows a typical PLC operating cycle, with an input scan, program scan or run-through, and output updates, along with internal checks. (Diagram from PLCdev.)

The other way to approach the problem is from the application level.

Complexity: This can mean a number of things, from the number of inputs and outputs the application has to how fast things need to happen. How frequently does the application need to be updated? This also ties in to the requirements of the PLC itself. Also, the complexity of the program itself; what is the program doing? Is it executing some complex algorithm or doing fairly simple control like opening or closing valves, starting/stopping a motor, etc? Is there one motor or are there five or more? This makes a big difference.

I/O: As in the case of the PLC itself, the number of I/O the application needs will determine the PLC needed for the job. This is also related to complexity. Is it a large machine with dozens or hundreds of I/O or a simple process control with a few I/O?

Controllers like this Allen-Bradley CompactLogix 5380 from Rockwell Automation are aimed at machine builders requiring motion control functions. It features expandable I/O and support for up to 20 motion axes via EtherNet/IP.

Like so much else in engineering and design, you have to make sure your application demands match up with the PLC you choose. An underpowered PLC will perform poorly in a complex application. Likewise, you don’t need a PLC on steroids for a simple control task. Know your application (current as well as future demands) and choose your PLC accordingly.