A programmable logic controller (PLC) is essentially a term used for any controller these days. A programmable automation controller (PAC) is the alternative. It could be looked at as a flip phone vs. a smart phone. However, there are distinguishing characteristics.
Programmable logic controllers are designed for real-time control of industrial machines, processes and manufacturing lines. They can be programmed in ladder logic, and some allow structured text, or function blocks. Compared to PACs, PLCs will have less processing power; thus, PLCs should hand data off to an historian or database system. PLCs are great for straightforward automation tasks like opening gates, solenoid banks, conveyor systems and safety systems.
Programmable automation controllers have more memory and can be programmed with C or higher-level languages. They have the capacity to be a PLC plus an historian and allow for more systems based on Ethernet and overhead connections. Thus, distributed controls should use a PAC. Single machines can just use a PLC or a combination of a PLC and a human-machine interface (HMI).
Obviously, costs increase with PACs, but the flexibility does, as well. Some PACs can take up to 200 or more remote input/output (I/O) racks. Motion control is easier with PACs, and, if you want refined controls, then a PAC is the choice. However, the cost increases. For instance, one PLC brand can be bought at around $1,500 dollars, while it's PAC equivalent is going to be closer to $10,000.
This is one of the driving factors when choosing a chassis, and why most designers will still list out inputs and outputs to get a count and discern the type of inputs and outputs before choosing a chassis. Knowledge of the process is also influential. Will the system need additional racks in the future? How will they communicate? These are questions that need to be answered by a designer when choosing a chassis.
The advantages of PACs include processing power, so code can be more complex. What does this mean? Historical systems may have put Level 2 controls on a server or in an application environment housed on a separate computer to allow for loop calculations or any other complex processing.
Once the answer was obtained, then the Level 2 controller would send the data to the Level 1 PLC, which would output to the field device and receive feedback to put back into the algorithm. This was OK because PLCs did not have lots of memory but could relay and receive data. Now, PACs allow for loops and complexity to happen in the controller in the field.
Typical scan times on a PAC are 10 microseconds to 10 milliseconds, depending on the load. A scan time usually consists of a cycle in which the controller reads inputs, executes logic and writes to outputs. Thus, controller load is dependent on inputs and outputs, as well as on user-defined logic.
Does user-defined logic matter? Yes. Writing code in an efficient manner and thinking about project execution is ideal for having reduced run-time errors. Effective coding will reduce loop times, ensure no divide by zeros, ensure no array out of bounds and will not have null pointer dereferences.
Other issues include timing. Some people no longer program under the idea of a main program running a bunch of subroutines. Instead, programmers will implement tasks and then set the timing per tasks. Typically, tasks are used as a scheduling mechanism for program execution, and programs are a set of related routines and a collection of tags. Routines are a sequence of logic.
Get your subscription to Control Design’s daily newsletter.
One way of coding is to follow the scan time sequence and to write a routine that gathers all the physical inputs and moves them into the logic registers for manipulation. For instance, in a motion routine, it is ideal to read proximity switches to indicate where a conveyor tray might be located and whether the tray is loaded before executing a pick for the robot. Otherwise, a command could be sent to tell the robot to move, and then it goes to pick empty space. This is a waste of time.
See how mapping out sequences in advance and understanding how the system will be integrated might affect the controller chosen and how its programmed?
Controller organization and logic execution issues may be less evident in a PAC, if there is little user-defined logic, but it can still affect machine execution. What if you have a bank of motors that need to work in sequence? What if you change states before the scanner gets information off the pallet?
The scenarios are infinite, and code is never perfect. However, PACs make the struggle to code effectively easier because they have more power. Programmable logic controllers might be simpler and less of a headache to implement, and they cost less. Remember to choose the best tool for the application, and it won’t be wrong.
