Interested in linking to "PLC Programming"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
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:
In order to meet these criteria, safety PLCs include special design characteristics, such as:
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:
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.
Job well done, Bedford Associates Project 084 Group. Thanks!
Dave Harrold is a Control contributing editor and co-founder of the AFAB Group.
ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.