FINAL THOUGHTS

PLC Considerations

When selecting a PLC or similar control engine there are many questions:

1. How much I/O?
2. What type of I/O?
3. What type of control logic -- simple ON/OFF or is there PID and data analysis?
4. What type of data is monitored and captured?
5. Are there recipes (databases) involved?
6. Is there an operator interface involved?
7. Are there special communication interfaces required? For example, flow meters, scales, thermocouples, or other signals that are not a regular discrete or analog signal.
8. Does the application require links to an external network, database, or some type of MES system?
9. Does the application require motion control, bar coding, machine vision, etc?

PLC and / or Computer

Sometimes we do not use a typical PLC for the control engine. Typically what we do is:

1. If the application is small (less than 50 I/O), no databases (only a few choices), and simplistic HMI then use a PLC.
2. If the application is small, slow (response time greater than 50 milliseconds) and requires computer functionality (machine vision, networking, databases, multiple axis motion control, etc) we prefer to do the entire application in Visual Basic (VB).
3. If there are large amounts of I/O (over 100) or you need fast, real-time response, then you will probably appreciate the PLC handling your real-time and direct I/O tasks and letting the computer handle the non-real-time tasks (such as HMI, databases, etc). There are a lot of gray areas in between.

Although today’s Pentium III running Windows NT or 2000 at 1 GHz with 512 KB RAM is very fast in comparison to technology only three years ago, it is still nice, in large systems, to use a PLC to help segment the system functionality. You can write subroutines to segment functionality -- you can also segment using different controllers.

Frequently Asked Questions (FAQs)

1. What about soft PLCs? Soft PLCs are where the PLC is actually software that resides on a computer. Although this is way that the industry is headed for the future, as with all new technology, we would recommend that your first test of new technology not be a critical application.
2. What brand of PLC is the best? It depends. J If you have a plant full of GE PLCs then it does not make sense to change to AB. If you have a plant full of some manufacturer that is no longer in business and you have to switch anyways then it may be time to reevaluate. If you have small applications that can be linked by computer networks then an AutomationDirect PLC may be fine. If you have large processes (thousands of I/O) requiring integration of drives and redundancy then you may want to consider AB or Siemens.
3. How can you program so many different PLCs? Most good PLC programmers, after learning three different PLC programming languages, can program most any PLC since the basic functions are the same. In fact there is an International PLC programming standard (IEC 61131-3) that your best PLC manufacturer’s are adopting.

To learn more

There is a lot you can learn about PLCs.  For example, there are books written on PLCs and some of these books do not seem complete.  If you want to learn more, there are many good resources.  As always try searching the best source of information -- the internet.

LADDER LOGIC

PLCs are traditionally programmed in a notation known as Ladder Logic or Relay Ladder Logic. This notation is easy for technicians to read and understand. Remember that the first PLC’s were designed to replace large numbers of relays and they were designed to be easy for the electricians responsible for those systems to be able to analyze and troubleshoot.  You might want to note that a background and understanding of basic electrical circuits is helpful if you plan to program or work with PLC’s. 

An example of a simple motor start/stop circuit is shown below:

 Assume that A is the "start" button, B is the "stop" button and C is the output that tells the motor to run. Imagine power flowing through the ladder logic example. In this case when the operator presses the "Start" button (labeled A above) power flows through the contact labeled A. The [/] contact means "not on" or off. So assuming that the "stop" button (labeled B above) is not pressed then power flows through the B contact and powers the output labeled C and turns on the motor.

Note that we have another contact labeled C below the contact labeled A. This is called a "seal" circuit since contact C "seals" in contact A. Remember the power flow analogy. If it was only the top row: A, B, and C then every time the operator took their finger off the "start" button (contact A) then the motor would stop. But contact C is placed in parallel with contact A so that once the output C turns on then the input C is turned on in parallel with contact A. Therefore the only way to stop the motor is to press the "stop" button (contact B).

Relay ladder logic - RLL) is the basic PLC logic that converts inputs into outputs.  There are several other methods for writing PLC code.  Sequential Function Chart (SFC) is excellent for the programming sequential machines -- however most customers hate it.  Therefore we usually provide the same framework in RLL.   Structured text is another available programming language – much more like a standard high-level language.  Function blocks are also available now on many processors.  Seen used more in DCS (Distributed Control Systems – a completely new discussion), function blocks are somewhat like a “black box” in electronics.  They have a defined set of inputs to the block (don’t get them confused with the PLC inputs) and a defined set of outputs (ditto).  The block performs a manipulation of the inputs to elicit appropriate outputs.  This can greatly enhance the computational ability of the PLC and simplify some applications.  Once again – most clients want to stay in the RLL world.  The number 1 rule associated with PLC programming is “keep it simple.”  Most end users of PLC’s do not have PLC programmers on staff, or if they do many times those programmers are not the people that are called at 3 am at night when a machine is down.  Generally it’s somebody off the maintenance staff that gets pulled in to solve the problem.  The simpler the program – the more likely the problem is diagnosed and fixed quickly. 

There is an organization that is working to standardize the logic in all PLCs.  More information on this can be found at The PLCopen (IEC 1131-3)

SYSTEM ARCHITECTURE

PLCs are continuously expanding in capabilities and the architecture or hardware that is part of that is also expanding with new functionality.  There are some hardware components that are basic to every system.  A PLC system generally has the following components:

1. Processor – consists of the CPU, main memory, possibly some communications and interface capability.
2. I/O – short for Inputs and Outputs – sometimes included in small quantities on a block with the processor
3. Power Supply – Provides power for the various components of the system -sometimes built into a block with the processor.
4. Rack/Chassis – Modular systems generally need a common backplane to plug into.  Racks are designed to at least accept a processor and multiple I/O cards.  Communication from the processor to the I/O is generally achieved through connections on the rack and power from the power supply is generally distributed through the rack.
5. Communication interfaces – used to communicate with the programmer, operator interfaces, data monitoring tools, SCADA systems, remote I/O, etc.  Sometimes built into the processor.
6. Programming Tool – used to program and access the processor.

The processor is generally what most people refer to when discussing a PLC.  Many controls specialists (including myself) tend to interchange PLC, processor and controller when referring to the module that receives the program and handles processing the logic.  All of the components together are generally referred to as a PLC system.  The processor is where a PLC program would reside and is responsible for receiving data from the input cards and distributing it to the output cards

I/O cards or Input and Output cards are the connections to the real world for the PLC system.  As discussed there are discrete I/O and analog I/O.  Both come in many different types.  Discrete I/O can come in various voltages:  24 Volt DC or AC; 120 VAC; TTL; sourcing; sinking; and on and on.  Analog I/O has even more variety.  There are Voltage inputs/outputs, Current inputs/outputs and cards that handle both.  There are cards that just grab inputs or outputs and cards that have a mix of inputs and outputs.  There are cards that are specially designed to connect to Thermocouple and RTD sensors and to compensate for the non-linearity of the signal.  I/O can also be local or remote.  Local I/O is located in the same rack or chassis as the processor, whereas remote I/O can be located in a separate location that is more convenient to wire into. 

The Rack or Chassis is used to house the PLC processor, I/O cards, and other cards that are needed with the system.  Some smaller block style PLC systems don’t use racks and even some modular style systems have cards that stack together with each card having the required connectors to pass processor communications and power to each subsequent card.

There are many available communication interfaces ranging from cards designed to communicate via Ethernet to specialized cards designed to communicate on a manufacturers proprietary communication link.  Generally those cards are used to allow the programmer to interface with the controller, another device to interface with the controller, or to allow the controller to manipulate and read I/O located in a remote location.

Programming interfaces vary from handheld programmers (yuck) to more modern programs that can be installed on a laptop to interface and program the PLC.

BASIC SIGNAL

There are a lot of different types of signals that PLCs can read and write. The two most basic signals are discrete (digital) and analog. Discrete means on or off, 1 or zero, high or low, etc. Two possible states. Using discrete signals you could have a switch that when pressed starts a motor running.  Both the switch “input” and the motor start “output” would be discrete signals.  Analog signals are continuous signals varying between two limits.  Analog signals can have a multitude of different values between those two limits such as pressure, temperature, level, etc. 

Early PLCs were designed primarily as relay replacements.  Those PLCs were designed completely around discrete applications.  They were a fantastic improvement over the rooms of relays that were used to operate what would be considered now simple sequences.  You can imagine the improvement it would be to be able to add a new discrete input and output into your program as opposed to having to wire a new relay into an existing system. 

 A single discrete signal is also referred to as a "bit". Although they sound very simple, bits can be used in a lot of different ways. For example, by turning a bit on and off you can generate pulses. By using a bit going into a counter you can count the number of times the bit turns on. For example, if you have a motor and each revolution of the motor moves the crane one foot, and you need to move the crane six feet, then you would simply count six pulses. You can also have a bit go into a timer. So if the crane moves one foot per second, then the "crane is currently moving" bit starts a timer that in six seconds tells the PLC that the crane moved six feet.  Typically however, discrete signals are used for simple applications.  Starting a motor or opening and closing valves.  Not glamorous, but very useful

A single bit can have two states – one or zero. Two bits can have four states (00, 01, 10, and 11). Eight bits is known as a byte and can represent 256 states or the numbers from 0 to 255. This is how computers represent numbers and values – by cascading bits.  The PLC is no different.

Analog signals involve detecting different levels of a signal. For example, how fast you want to run a motor. With analog signals, the user can turn a potentiometer that generates a varying voltage or current (analog input) that tells the PLC to send an analog output to the motor indicating the speed that the motor should run. Technically you would need something like a motor inverter between the PLC analog output and the motor to essentially amplify the PLC analog output to control the motor voltage or frequency and vary the motor speed.

You can represent the position of the potentiometer using 12 bits (0 to 4095). Zero voltage (or current) would be represented by 0 in the PLC and 4095 would represent the maximum voltage (or current). Theoretically (assuming no noise, perfect linearity, and a few other things), the PLC can run the motor at one of 4096 different speeds.  Analog signals can be used to bring many types of continuous signals into the PLC – temperature, pressure, level, position, etc.  Once in the PLC memory, these signals can be manipulated to control motors, valves, and other field devices. 

Let me reemphasize that the function of a PLC is to read these discrete and analog inputs, run some logic based on those inputs, and then write discrete and analog outputs to control the available environment.  

PLC EXAMPLE

Let’s start off with a simple example. Suppose you are making a controller for an overhead crane. The operator has a simple control box with four push buttons: "left", "right", "up", and "down". When the operator presses the "left" button (note that the "left" button is an input to the PLC), then the PLC turns on the appropriate output to the motor that makes the crane move left. The other three buttons would operate similarly. Sounds pretty simple – right?

Suppose it takes ten minutes for the crane to reach the full left position. Soon the operator’s fingers start to hurt (holding that button down for ten minutes at a time hurts), and they are going to beg / bribe / threaten you, the programmer, to latch that output on and add a stop button. Instead of having to press the "left" button for ten minutes, the operator wants to momentarily press the "left" button and the crane keeps moving left till the operator presses the "stop" button. So you reprogram the crane and now the operator picks up a 10 ton container, presses the "left" button, realizes he forgot to get a drink (of water), and knowing that the crane will be moving for ten minutes, goes off to get a drink. Or suppose the crane hits the operator and knocks them out. Who is going to stop the crane? There are some major safety considerations since you have a 10-ton container moving around with no one to stop it.

So you start adding safety light curtains and mats around the crane’s operational area, so that if anything comes into the crane’s operational area the crane automatically stops. You would also add Emergency Stop (E-Stop) buttons around the area so that anyone can press one of these buttons to stop the crane. You would want to add end-of-travel limit switches so that when the crane moved as far as it can go then the PLC would automatically stop the motor. You would also want to add some more inputs (feedback) to the PLC so that when a motor fault occurred the PLC would detect the fault, turn off the motor, and sound alarms. There are many other safety and diagnostic inputs you should add.

Do you see how a very simple application can grow in inputs and outputs very quickly? The good news is that by using a PLC for this application the PLC is very quickly and easily reprogrammed for the new inputs. Other wise you have to go get more relays and do a bunch of wiring for each new input and output.

Even More Complexity

We can extrapolate this simple crane into more complex systems:

• A "crane" that automatically loads or unloads 55 gallon drums onto pallets, containers on or off a ship, or adds a finite amount of reagent to a matrix of test tubes.
• Multiple cranes that have overlapping work envelopes and require collision avoidance and cooperative handling
• "Cranes" that work in three-dimensional space to store and retrieve items. Applications from electronics to pharmaceuticals show that automated storage and retrieval systems reduce errors significantly.
• Two axis controllers that move a video camera around for inspecting parts

The control systems engineer sees a lot of similarities in these different applications. All of these applications can use a PLC but these applications are just a tiny subset of all the control schemes that employ PLCs.

PLC MINI-TUTORIAL

This document is designed to give an overview of what a PLC is, what it is good for, what it is not best at, an overview of its operation and where to find more information. A Programmable Logic Controller (PLC) is a rugged special purpose computer that reads a bunch of input signals; runs control logic, and then writes output signals. After reviewing this mini-tutorial please feel free to ask us questions or ask about a free seminar and demonstration at your site.

Pros

1. PLCs are good at turning outputs on or off based on the state of inputs. (control)
2. PLCs are good at bringing together and concentrating a lot of data and status that is uploaded into a computer in a compact form
3. PLCs are more rugged than computers and typically last five, seven, ten years without needing replacement

Cons

1. PLCs are not the best at handling large amounts of data or complex data.
2. PLCs are not the best at reading and writing databases.
3. PLCs are not the best at outputting resultant data to printers.
4. PLCs are not the best at displaying data and information to the operator.

History

Programmable Logic Controllers (PLCs) have been around since the dinosaurs. In fact it was PLCs that killed the dinosaurs. Don’t listen to those people that tell you that dinosaurs were killed off by global warming / cooling, meteors, or even smoking cigarettes. PLCs killed the dinosaurs. You see, millions of years ago the cavemen used PLCs for everything they did. All of the dinosaurs lost their jobs, couldn’t afford to buy food at the local stoney-mart and just died off.

Okay, okay I guess I have to admit that the last paragraph is not true. But the PLC has been around since at least the 1960s, which in technology years makes it a dinosaur. For the real history of the PLC follow this link  to the website of Dick Morley, the inventor of the PLC (just don’t forget where to come back to).