Dick Morley, the "father" of the PLC explained in a recent exclusive interview, "Our design philosophy was simple; put a bunch of relays in a box!"
At the time, Morley was working at Bedford Associates, and because this was the 84th Bedford Associates project, the first Programmable Logic Controller (PLC) was dubbed "084." Eventually the team named its invention the MOdular DIgital CONtroller—Modicon for short—and the rest is a well-documented history of the PLC.
The PLC was born in the early years of microprocessor development, when all sorts of software development languages were emerging, so the question occurs: "Why choose Relay Ladder Logic (RLL) as the programming language for the PLC?"
To that question Morley is quick to reply, "Technology doesn't count. It's what you do with the technology that counts. Because our philosophy was to put a bunch of relays in a box, we felt that ‘our box' was more likely to secure user acceptance if it ‘felt' more like what plant-floor users already had accepted and understood, and that was RLL. You see, at the time we created the PLC, we viewed, and still do, that PLC users are really the plant floor electricians and instrument technicians. Since these folks rely almost exclusively on RLL schematics to do their troubleshooting, it made sense then, and it makes sense now, that we provide them access to technology in a way that they are already comfortable using, and that is RLL."
Obviously, the decision of Morley and his buddies working on project 084 was the correct choice because, despite the existence of the programming standard IEC 61131-3 and its inclusion of Sequential Function Chart language and four interoperable programming languages (Instruction List, Ladder Diagram, Function Block Diagram and Structured Text), RLL remains the programming language of choice among users and integrators worldwide for most PLC applications.
The original creator of RLL schematics is lost forever in the chronicles of history, but we do know that during the 19th Century's Industrial Revolution, ladder logic schematics became the preferred graphical illustration method for a wide variety of electrical control systems. Today RLL schematics are found glued to the back of your dishwasher and clothes dryer, included in your refrigerator and garage door opener user manuals, and tucked into panels throughout processing and manufacturing plants worldwide.
Why? Because a recent discussion about RLL's popularity on the plctalk.net forum produced similar responses from Bob in Australia, Cameltoe in Tonga, Nathan in Korea, Thomas in U.S. and Sergei in Canada. Each said in their own way that RLL enjoys worldwide acceptance because it's an intuitive, graphical means of depicting both simple and complex control logic.
Jean Pierre Vandecandelaere, a trainer with VDAB Competentie Centrum in Belgium, explains that, "I teach seven different brands of PLC, and the elements of relay ladder logic schematics differs very little from brand to brand."
Mark Muhaw, an automation engineer with Ind-Concepts (http://plctrainer.net/) in South Carolina, provides another legitimate perspective about RLL's universal appeal, "My clients expect me to turn over PLC implementations that don't require them to contact me for on-going support. If they ever do need my support, I find that RLL makes it much easier for me to get myself back-up-to-speed on a particular implementation months or even years later."
So there you have them. The three top reasons why relay ladder logic remains the control language of choice of PLC users worldwide: it's easy to learn; robust to use; and is transparent across a huge number of platforms.
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!"
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.
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."
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.
The article was first published in controlglobal