Should I limit programming to ladder logic or use all standards within IEC 61131?

A Control Design reader writes: Due to past issues with programming support of our automated machines, we have created a requirement for new equipment that the control software meet the IEC 61131 standard, and we have limited the approved controller manufacturers. However, that fixed just some of our support problems. Each machine supplier seems to have its own, varied opinions on how to write a program for an automated machine cycle, and a few think it should be written like it's process control, even though its discrete control.

Some of my team members think we should allow use of all the programs available within the IEC 61131 standard, and others say to limit the programming language to ladder logic, in most cases, and document the acceptable program structure to keep it simple. How can I box in the control software and machine control programming methods on equipment supplied to our manufacturing plant to ensure my maintenance technicians and programmers can provide quick, efficient support? Also, how can I standardize to make the control software easier to use and understand when troubleshooting?

Get AMPed

Trying to maintain a plant with numerous dissimilar machines from disparate vendors can be very daunting, especially when those vendors are all programming their machines to different standards and using different hardware. Your attempts to limit approved controller manufacturers and require vendors to meet industry standards such as IEC 61131 are excellent first steps, but they are just that, first steps.

While standards such as IEC 61131 are outstanding documents, they are also, by design, very broad and open to interpretation, as I’m sure you are seeing. What it sounds like you really need is an automation master plan (AMP) that is written specifically for your plant that all vendors would be required to adhere to.

The AMP would specify not only approved controller manufacturers, but specific models, and it wouldn’t be limited to just controllers either. It would specify I/O modules, field instrumentation, control panel and networking requirements, drawing standards and the like. On the software side, it would specify which languages—for example, ladder logic, function block, structured text—are acceptable to use based on your maintenance team’s familiarity with them and when it is appropriate to use each one.

It would spell out specific program structure and could even contain low-level libraries that all vendors are required to use in their code. Program documentation requirements such as rung comments and tag-naming standards would also be addressed. Other important aspects of any good AMP would be change control, revision tracking and disaster recovery if those procedures don’t exist elsewhere.

All team members from engineering to maintenance and operations, should all have input into the AMP so that there is a feeling of ownership, which in turn will aid in the buy-in process. The AMP may seem a bit intimidating, and you may not have the in-house expertise or available bandwidth to author it yourself, but I’m sure there are several qualified system integrators in your area who could assist you in generating one. The time and money spent on the effort would be more than made up for in reduced downtime and increased productivity.

Mark T. Fisher, ISA-CAP, CFS / senior director / Thermo Systems / Control System Integrators Association (CSIA) member

Seek integration

The debate on the best methodology for writing and structuring programming code is as old as the first computer and very subjective. We do not claim this standard, but in essence we follow it.

This particular standard references four approaches, two textural and two graphical. You cannot standardize on just one because you cannot practically apply one of them to fit all applications.

Just simply referencing this standard does still leave the door wide open to problems for end users. The primary goal should be to have code, regardless of the methodology, organized and documented in a consistent fashion and manner that is easily followed by your technical staff. This also provides consistency.

Companies should develop requirements and standards for their integrators to follow. If they do not have the resources or technical expertise to develop such standards, most integrators can help with this development.

Curt Austin / engineering director / aeSolutions / Control System Integrators Association (CSIA)

Requirement spec

The only way to have an equipment supplier comply with your specific programming standards would be to write a detailed programming-requirement specification and supply it to the supplier, along with your request-for-proposal (RFP) package. IEC 61131-8 is a general guideline for the application and implementation of all the IEC 61131-3 programming languages and is a good reference for building a programming-requirement specification. Forcing the equipment supplier to follow your specs will ensure that all of your new equipment harmonizes well with your existing equipment. Complying with your spec will also make the learning curve for your technical staff relatively small, regardless of the chosen controller manufacturer.

Matt Lyles / product specialist & application engineer / Bedrock Automation Platforms

Ladder logic limitations

Limiting programming to only use ladder logic can have the reverse effect of making the program harder to troubleshoot as different equipment suppliers will have different strategies to work around the limitations of ladder logic.

Chris Harlow / product and customer service manager / Bedrock Automation Platforms

Transcendental PackML

IEC 61131 is designed to allow the most appropriate language for the task at hand. I would advise against restricting to only using a single type of programming language. For example, structured text is typically the best for performing calculation and conversion types of tasks. Forcing everything to be solved in, say, ladder, can make some significant challenges. Sequential flow chart programming can be an excellent tool to step through discrete control processes.

One of the most effective uses of IEC 61131 is to create user-defined function/function blocks, or libraries, of commonly used sequences. These libraries are then used in projects so that underlying code is common across projects. This will somewhat limit one programmer programming a task completely differently than another program.

We have compartmentalized things inside a “toolbox” or library that can be included in a project. The user can then select items from the toolbox to use in the project, rather than recreating the wheel each time.

Another tool that some packaging end users are demanding in their programming architectures to have common troubleshooting across different OEM pieces of equipment is packaging machine language (PackML). PackML is an industry standard for the control of packaging machines developed by OMAC. It uses specific terminology to encapsulate machine control. While PackML was originally intended for packaging machinery, it is starting to be used in other industries.

DMC has put together a great intro on PackML.

Michael Miller / manager, regional motion engineering / Yaskawa America—Drives & Motion Division

Cobbled systems

One step you can take to improve standardization is to anticipate future needs when specifying equipment and exceed the bare bones of your current requirements. While it’s not possible to predict every scenario that might come up, planning for future additions can remove the challenge of cobbling together disparate systems later. Reducing the number of independent actors in a system streamlines both the process itself and the knowledge required to operate it. All-in-one controllers can be an easy way to streamline and simplify, as multiple components of the system can be programmed using the same software, at the same time.

Zachary Hampton / application engineer / Unitronics

Support support

Many large manufacturers have created detailed control-system specifications over the years. They have spent years or even decades updating these standards and developing control systems that use them. Not every manufacturer can spend that amount of time developing such standards. Modular programming can help to standardize control-system projects without having to go into such detail.

The key to implementing modular programming is to start with code modules that are small and simple—“small” meaning the code module only performs a certain function and does not branch off into multiple functions. This helps when reusing the code module. “Simple” means the code is easy to understand. Support personnel should not be troubleshooting the code modules; rather, that should be completed one level higher at the interactions between code modules. Many control-system vendors have code libraries you can leverage to standardize your modular code library.

Organization and naming are other low-hanging fruit. Increasing the commonality between PLC projects can help support personnel be more confident in finding code. This also helps with troubleshooting in other areas of the plant. It can be accomplished by starting projects with an accelerator toolkit from a control-system vendor or with a common base project that contains the organization, naming and code modules you want your vendors to use.

Also, do not forget about visualization. Ideally, most control-system troubleshooting would be completed from the HMI. It is important that all systems have common diagnostic screens and standardized diagnostic coverage. Solving support problems without having to go into the control-system design software can save the most time.

Jason Lakomiak / Studio 5000 Logix Designer product manager / Rockwell Automation

Front-end effort

The fact that you’ve created documentation of your requirements is an excellent starting point. Requiring that new equipment control software meet the IEC 61131 standard leaves your vendors a lot of freedom in choosing how to get a machine working, which can lead to the issues you described. From the vendor’s standpoint, a software project is complete when all of the requirements are met.

To box in the control software and machine-control programming methods, we’d recommend starting with defining the language or languages you allow the vendor to use in the program. Some vendors will take issue with this and some won’t; you will ultimately have to decide if a certain vendor is able to meet your needs or not. You should also be aware that not every IEC 61131 PLC vendor supports every IEC 61131 PLC language, so your choice of hardware should take into account which languages your equipment will use. Many times the exercise of documenting requirements can flush out technical or other issues that wouldn’t be found until later in a project. The more effort you put into the requirement documentation on the front end of your project, the better your final product will be.

Which language to use is an age-old argument. We often compare programming languages to tools in a tool box—each has its own strength and weakness, but all are there to serve a purpose. Some are older tools and are there for that one job they are still useful for. Some are new and can do a variety of tasks.

We’d argue the most modern approach to the IEC 61131-3 programming structure is to use the following:

• sequential flow chart (SFC) to define the states of the machine
• ladder logic (LD) to define the sequence of tasks within each state
• structured text (ST) to write any functions or function blocks to do the heavy lifting.

The thought behind this is SFC can easily be understood by the operator, who generally is responsible for putting the machine into whatever state it needs to be in to run. LD is fairly universal and often still the tool of choice for maintenance technicians and electricians to be able to troubleshoot. ST offers many of the programming structures needed for higher-level functionality and generally is a programming language engineering staff will be comfortable with.

Usually what we see in practice with IEC 61131 PLCs is each program (PRG) is written in ladder and functions (FUN), and function blocks (FBs) are written in structured text (ST). It’s also worth noting that young engineers and technicians are usually very comfortable with ST, but keep in mind your installed base and legacy code may not support ST. If you go the direction of full ST, someone on staff will still need to understand how to go back and program those “old” machines.

Once you’ve decided on which language or languages are appropriate to use for your PRGs, FBs and FUNs, you need to define the structure of your program variables and naming conventions. When we program in IEC 61131 environments, we like to group things logically—all of the fieldbus I/O modules, PRGs, FBs, FUNs and variables have meaningful names. We also like to use the structure (STRUCT) user-defined data type, which allows grouping many different types of variables together into one logic structure or object. IEC 61131 also supports some aspects of object-oriented programming, which may or may not be useful in your applications.

While requirements documentation is only one part of an overall development project, it can become a project of its own. Providing your equipment vendors with clear and concise control software and machine-control programming documentation will result in your machines being easier to maintain, troubleshoot and upgrade, which will ultimately help your bottom line and lead to long-term success.

Kyle Hall / product engineer for fieldbus technology / Turck
Ethan Severson / senior product engineer for fieldbus technology / Turck

No language barrier

[pullquote]The struggle mentioned really has nothing to do with which programming language is allowed. Just limiting programmers to ladder will not really make support any faster or easier. One can find good code and bad code in any language. One of the big strengths of the multiple-language standard is being able to use the best-fitting language based on need.

Create a companywide machine-source-code guideline. Involve programmers and technicians to define a top-level program template that the company can use consistently on all machines and provide field technicians the chance to drill down to the site problem. Standardize on a language and required order of must-have items for that top-level program. Maybe use ladder or maybe a better choice is to use SFC, which is a visual flow chart of the machine sequence. Also take the time to define some specific troubleshooting must-haves or wish items.

Adding something as simple as a machine-state history list of the past 100 machine states can go a long way to improve troubleshooting. The rules should be fairly strict at the top level.

Define a naming convention for programs and variables. It is much easier to find things when you know what name to expect. PLCopen has a programming standards guideline, which provides some naming conventions along with coding dos and don'ts.

The guideline should also include commonly needed routines across all machines. Support becomes a lot easier when the expected handling is the same. For example, recipe management can vary wildly; it is sometimes handled in the HMI and other times in the control. Define a corporate-wide recipe guideline. Treat these items as mini programs; define the expected behavior, but not necessarily the programming language.

Don't forget to define an official review and update timeline. Guidelines should be periodically reviewed and adjusted based on field issues and new control concepts. Improve the guideline buy-in by making sure everyone knows how to suggest guideline improvements or changes.

A good real life example is PackML. PackML lives because companies hated that their Brand X machine and Brand Y machine did the same thing but had completely different HMI screens and setup procedures. Basically Employee 1 was an expert running the Brand X machine but couldn't run the Brand Y machine when Employee 2 was on vacation. PackML defines a machine sequence, responses to faults and reset procedures. PackML doesn't define a programming language; that is left to the developer.

A well-implemented guideline will not only improve troubleshooting response, but also becomes a training document for new programmers and field technicians, drastically reducing the "how does this company do it" learning curve.

Scott Cunningham / product and application manager, controls and automation / KEB America

IP protection

Well, since IEC 61131 was created, it has been a challenge to get all the manufacturers of industrial PLCs to agree and harmonize their software and hardware development into interchangeable systems that could be integrated into one bigger system.

Even though the IEC 61131 PLCopen and the five adopted programming languages were created with this intention, each manufacturer would have a different interpretation of when and how to use each one of the programming languages.

From a user perspective, especially maintenance teams, it became quite a challenge to keep a standardized programming practice within facilities or machines. This increases downtime and costs with maintenance, training and eventual support from a third-party company, or even from the PLC manufacturer itself.

Yet, some PLC manufacturers were more concerned with the maintenance aspects and found some ways to allow OEMs, or machine builders, and end users to work together, yet separately, as maintenance teams in the same IEC 61131 development.

Being in the automation industry for more than 10 years, I’ve seen a few of these programming practices and integration tools, but the use of the functional block (FB) is by far the most elegant and effective.

Allow me to explain a little more about this concept by first describing three of the IEC adopted languages. Ladder logic (LD) is one of the most common languages in the automation industry. Big and small companies use it broadly, mostly because of its simplicity. LD gives the user a feeling of designing an electrical diagram, which facilitated the migration of electrical relay-based panels into automation panels.

The structured text (ST) language is essentially composed by a few statements such as "IF" and "ELSE" organized and lines of codes. ST is, in fact, a more powerful language than LD, due to its capabilities to quickly compare and process many different data types simultaneously within a few lines of code.

And finally, let’s look at the functional block. There is a bit of controversy around this one. Some say the FB isn't a programming language, but a way of organizing and presenting different steps of your programming in the simplest way possible.

Whether it is a programming language or not, I would like to recommend using the FB to make your programming understandable and as easy as possible to troubleshoot.

One of the biggest advantages of using FB as your main IEC programming language is being able to use all the other languages and still present a programming environment where you only visualize and interact with FB. Not all IEC software developers will allow the users this level of customization.

It’s important to understand that, inside the custom function block, any programming language can be used, without affecting what’s outside. After all, the function block is a program itself. Spending some time developing a good function block that covers all the aspects of a specific machine or process with complete diagnostics will definitely pay off, not to mention that any custom function block can be replicated as many times as needed within the same program or in any other.

The good use of the FB will not just allow the developer to create a friendlier and easier-to-troubleshoot system, but can also protect the system and intellectual property.

Yuri Chamarelli / product marketing specialist—controllers / Phoenix Contact USA

Five editors are better than one

Logic controllers in a manufacturing facility can run the gamut from a 10 I/O “shoebox” to a multi-rack assembly with remote I/O, motion and HMI. Logic devices have many different labels, from programmable logic controllers (PLCs) and programmable automation controllers (PACs) to machinery automation controllers. In the end, all of the labels tend to mean the same thing, and they all boil down to a central processing unit (CPU) and an associated I/O chip set.

They all have an operating system—from the ubiquitous Windows to Linux variants. The operating system supports a series of tasks that execute, for example, logic, communication, motion and I/O programs.

IEC-61131-compliant software provides a programming environment to match the code with the task at hand. Under the umbrella of IEC 61131, there are five editors that can be used to convert an intended logic diagram to CPU machine code:

1. ladder diagram (LD)
2. statement list (STL)
3. function block (FB)
4. sequential function chart (SFC)
5. structured text (ST).

It is not the best use of resources to specify, for example, that an entire plant be forced to use an IEC 61131 platform and then further demand that only the ladder editor be used.

The purpose of IEC 61131 is that all editors be used, depending upon the task at hand.

One can see it most likely is not the best use of time to use SFC on an app that runs on a 10 I/O shoebox, nor is it the best use of time to use LD on a huge multi-rack remote I/O system. It is not that one couldn’t do this, but more that one shouldn’t do this.

A programmer should not be limited to a specific editor. Europeans use a lot of structured text because it is efficient. Coders working with PackML would gravitate to the state-machine capabilities of SFC. Process lends itself to ladder and so on. Most of the time, a program will employ several of these editors in the same program. A competent programmer should strive to embrace all of the editors and, if needed, seek the training to become proficient in all of the editors. Only then will electrical technicians have the tools to troubleshoot the variety of machinery in their plants.

Kenn Anderson / president / Nova Systems / Control System Integrators Association (CSIA) member

Click here to read part one of this Real Answers article with answers from six more experts.