PLC Programming

Figure 1. A typical relay ladder logic schematic for starting and stopping a motor.

Easy to Learn

RLL is simple. Relay ladder logic functions are illustrated with two vertical rails connected by several horizontal rungs, thus the name "ladder logic."  Typically, the two vertical rail are powered such that together they represent an electrical circuit. As with any electrical circuit, each rung must include some sort of electrical load (i.e., relay coil, indicator lamp, etc.) On/off control of each rung is achieved through one or more sets of contacts (i.e., relay contacts, pushbuttons, etc.) In a ladder logic circuit, normally open (NO) contacts are type-A contacts, and normally closed (NC) contacts are type-B contacts. Connecting multiple contacts in series where all contacts must be closed in order to complete the circuit forms an "AND" function. Connecting multiple contacts in parallel provides a means of completing the circuit when any one of the contacts closes, thus forming a logical "OR" function. Relay coils, whether real or a "virtual" device mimicked by the PLCs internal software, control one or more sets of contacts. When a relay coil is energized or "picked up," its NO contacts close, and its NC contacts open. Conversely, when the coil is de-energized or "dropped out," its contacts return to their normal (shelf) state (Figure 1).

Instructor Bill Simpson of The Learning Pit advises, "Based on teaching PLCs for 15-plus years, there's one thing that I can guarantee that you will find out about PLCs and particularly about RLL. The simple programs and instructions you learn early in your training are by far the hardest to grasp and clearly understand. As you advance, you'll be amazed at how much easier it all seems to get! So, take heart, take it slow, and don't skip to those advanced instructions until you know the simple ones by heart. Yes, they really are that important!"

Reliable and Robust

During discussions about RLL's popularity, Morley, with his unique flair for explaining things, adds, "Most software development languages are ‘go to' languages, meaning the program jumps from routine to routine based on the results of the current routine. Without a really good structure and extraordinary discipline by everyone that ever touches that software, unexpected and often undesirable and even disastrous results can occur. Pure RLL is a ‘come from' language. That means if one line or rung of the program is incorrect, nothing drastic is likely to happen. It's this fundamental difference between a ‘go to' and a ‘come from' language that enables RLL's robustness. When you think about it, each rung of RLL is really a complete program. It's that simplicity that allows the guy or gal, who is usually an electrician on third-shift, to quickly deal with a problem they find."

Of course it's understood that having a robust programming language is nearly worthless if the hardware isn't equally robust. In that regard, PLCs have established an unprecedented record for reliability and availability in applications ranging from chicken farms to amusement parks, and even on the International Space Station.

The inherent notion that the term PLC implies reliability was established by the Modicon project 084's developers, and can be witnessed at Modicon's headquarters in North Andover, Mass., where an early Modicon 084 that provided nearly 20 years of uninterrupted service at a General Motors manufacturing facility is on display.

Eventually the PLC's reliability became so legendary that it was used in safety applications.

RLL in Safety Applications

Though some will argue that any PLC can be used in functional safety applications, there is a class of PLCs available that have been specifically designed as "Safety PLCs."

The fundamental differences between a conventional and a safety PLC is that the safety PLC is designed to be fault-tolerant and fail-safe, meaning:

• A single fault in the system must not create erroneous inputs or outputs, nor prevent the system from performing its designed purpose;
• All detected faults must be alarmed and provide indication of the nature and location of the fault; and
• Any single fault must be repairable on-line without interrupting the safety PLC's operation.

In order to meet these criteria, safety PLCs include special design characteristics, such as:

• Robust internal diagnostics of hardware and software;
• Use of special software techniques to ensure software reliability;
• Use of on-line hardware redundancy with automated switch-over and recovery capabilities; 
• Exhaustive testing and certification designed to ensure the safety PLC conforms to relevant international safety standards.

Among the risks of using a conventional PLC as a safety PLC is overcoming the tendency of electricians and instrument technicians to use conventional PLC troubleshooting techniques on safety PLCs. For example, most conventional PLCs permit persons with proper login credentials to bypass inputs, force coils, reset timers, disable outputs, etc. Using those sorts of "on-the-fly" practices simply isn't acceptable in functional safety applications. In fact, such practices are often banned and/or are subject to rigid change control procedures.

Several approaches have been designed to prevent unauthorized and/or unsafe changes to safety PLCs.  One of the latest is the use of pre-engineered, pre-tested software modules that can't be modified, and that have been third-party-certified by such organizations as TÜV Rheinland Industrie Service  GmbH.

Certified pre-engineered software module availability varies from manufacturer to manufacturer, and the available choices often reflect the needs of a specific industry served by the PLC manufacturer (i.e., process verses discrete manufacturing verses transportation). When evaluating pre-engineered modules, pay close attention to these characteristics and features:

• Alarming per good engineering practices, such as EEMUA 191;
• Pre-engineered failure handling, especially important for sequencing modules;
• Standardized operator graphics, which are often optional, but usually worth the additional cost;
• Richness of the library of modules;
• Off-line simulation capability; 
• Managed by-pass handling.

One of the things you may find when examining pre-engineered functional safety software modules is that these modules often are written in a IEC 61131-3 language other than RLL. Initially this may seem like a serious drawback from a maintenance perspective, but it's important to keep in mind that safety PLCs have an entirely different purpose than control PLCs. It will be very rare that electricians and instrument technicians are troubleshooting or even viewing the software of a safety PLC, so when evaluating safety PLCs, it's best not to get locked in to thinking, "It must be RLL or nothing."

Listen to the Users

So far, we've seen 40 years and counting of advances in microprocessors, memory chips, operating systems, programming languages, communication protocols, etc. Yet through it all, the programming language of choice for the PLC remains essentially unchanged. Why? Because in 1968, the inventors of the PLC listened to their users. Today users can quickly and efficiently interpret the RLL hosted in any one of a dozen different brands of PLCs because of RLL's transparency.

Job well done, Bedford Associates Project 084 Group. Thanks!

Dave Harrold is a Control contributing editor and co-founder of the AFAB Group.