Keep it simple with ladder diagram

Ladder diagram is all that is needed for typical machine control applications. Do yourself a favor and use it.

By Dave Perkon, technical editor

1 of 2 < 1 | 2 View on one page

Standards are important, but, as with most standards, often only a portion of it is widely used.

The IEC 61131 Open Programmable Logic Controller standard is an example of that. Although the IEC 61131 standard has four programming languages and a structural component and defines data well, just sticking with ladder diagram, the de facto standard for PLCs and PACs in discrete manufacturing and process skid applications, will save you money and keep you efficient in the future.

Although personal preference plays a role, using just ladder diagram programming for machine sequence control keeps things simple for an integrator's controls department and the customer's support and maintenance department, and that’s what most machine builders want. The quicker the customer can support the equipment, the better. Sticking with ladder diagram helps, as the majority of programmers have little need or awareness of the IEC 61131 specification even though it has been around for more than 20 years.

Although the IEC 61131 standard is useful and has its place in more complex applications, most programmers do not save time or money by using multiple programming languages. Ladder diagram and maybe some function block programming is all that is needed. Mixing several different languages in a single program is less efficient from a programming and support standpoint.

It adds more time and costs during development, testing and maintenance of the program. It can also make it more difficult for the next guy to figure out the program when using multiple programming methods. The syntax is different between each type of program and must be learned before it can be supported, and some are just a waste of time.

Also read: What the ability to design or program a simple start/stop circuit says about you

 Sorry instruction list programming—the days of low-level programming are over, and I cannot think of anything but the most limited applications where you would want to write single instructions in a line-by-line format. I did work on a machine from Germany several years ago that strangely used instruction list. They like it, but it is impossible to comprehend why a large integrator would write a program for a $5 million machine using instruction list. It was massive and very difficult to understand where to start or what the program structure was, and it was in German. Nein! If you ask me, instruction list programming is not necessary and a bad idea, so don't use it.

It's not the complexity of the sequence or process as much as it is the poorly written program that makes it difficult to support.

Structured text has its uses for data handling, string functions and math, among others, but most can be done using ladder. It's also good for iteration loops, but doing it in ladder eliminates the need to understand another syntax and tie two different programs together.

The sequential function chart structure may help to define process or machine sequence flow, but each block in the chart has additional programming behind it that must be managed within the program. There are too many bits and pieces. Just reset a sequence in the middle, and there will be many small sections of logic that will need to be cleaned up, reset and initialized, and the chart structure hides it nicely. Not my favorite.

How-to: the important standard

A how-to standard can better help the average PLC programmer, technician and maintenance worker by creating well-thought-out ladder diagram programming techniques, as opposed to defining what ladder diagram, function block, structured text and instruction list programming languages and sequential function chart structure are. The programming environment typically doesn't need the "what"—at least not in the United States—they need the "how." The what has been done already.

Often the reason software costs so much to develop and maintain is that the program is poorly written. I've seen a program that was a single rung with 200 branches. The programmer thought the structure was great, and so was the gray code he used to control the sequence, until right before he was fired. Most often, I see what I call scatter code—the incredible wandering PLC program where rungs of logic are just randomly placed with no thought to purpose, function or organization. Focusing on proper programming structure and techniques is what is most important.

Also watch this webcast: The fundamentals of IEC 61131 

1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • Hi Dave. I disagree. The programmer should use the best tool for the job. He/She should also create re-usable code by creating their own function blocks and functions. I usually use ladder diagram, function block diagram and structured text in my programs, using whichever tool is best suited for that portion of the program. Most users who grew up with PCs will find structured text and FBDs quite intuitive to use. Regards, Tom

    Reply

  • You are are right on Dave, great and much needed article. Your "[ladder logic] keeps things simple for an integrator's controls department and the customer's support and maintenance department, and that’s what most machine builders want. The quicker the customer can support the equipment, the better." needs repeated here. Your advice (wisdom) is right in line with best practices outlined at http://plc-training.org which echos most of the points you made.

    Reply

  • I draw several issues with this article. First, poor code can exist in any programming language. Second, ladder logic (boolean TRUE/FALSE logic) is at the same logic level as IL (if not lower). Third, the author mistakenly assumes that the workforce understands ladder logic. New hires don't - they must be taught. Colleges and Universities teach C, C++, Java and other high level languages - they do not teach ladder. Newly hired engineers actually better understand structured text (IF THEN ELSE) better than ladder. Ladder was created as a software replacement for relays and contacts. After 20+ years in industrial automation, I find it disappointing that our industry wishes to make new hires experts in low level relay logic. The automotive industry networks their cars with CAN now, I think the industrial industry can move on to "higher level" platforms.

    Reply

  • It is about time someone addressed this subject in an intelligent way. I worked in the industrial control field for 35 years and could not agree more with you, The last 14 years for a major Printing company which used many German presses. Fortunately on most of them the company specified they use an American (Rockwell/Allen Bradley) control system but on some equipment the supplier insisted they needed to use the original German control systems where almost all programming was instruction list. What a nightmare to follow and troubleshoot. Also the programming tools were years behind in usefulness. We need more people like you to spread the word, after all we are visual people so a visual programming environment is a real benefit, especially out in the field. Keep ip the good work.

    Reply

  • I disagree. It is this kind of thinking that holds the industry back from designing better machines. keeping this discussion in the realm of IEC 61131, there are multiple languages available for a reason. Each one has particular strengths and weaknesses. With the exception of Instruction List, I use all of the languages where they are most appropriate. I find that a lot of people prefer ladder on a machine because they claim that their maintenance people can support it. But my experience is that this is rarely true and I still get requests for support on even very basic situations. As an OEM, I do not want people in my code. and I am certainly not going to write bad code or only use ladder logic just so I make the maintenance tech at the plant still feel relevant because he lacks proper training. I think the real issue at hand is the lack of training and skilled workforce available in the US today. It would probably help as well if the prominent controls vender, Allen Bradley, had any other decent programming languages besides ladder logic.

    Reply

  • Overall, an excellent article. I find it odd that many experienced PLC programmers seem to have a very strong aversion to programming ladder logic in step-sequence (or a sequence of machine states). It seems every one I discuss it with either loves it or hates it. The ones who hate it tend to program by "the seat-of the pants". Later, as changes are needed, many times the customer is on the programmer's back because the machine or an entire line is down and to get the needed changes done in time, the logic is just patched instead of being done in an ordered way, and the problem continues to compound as time goes on resulting in the "scatter code" Mr. Perkon mentioned. I have seen a similar aversion to Rockwell's "Phase Manager" among "seat of the pants" programmers. However, regarding Mr. Perkon's characterization of instruction list programming as being "sorry", I would disagree. Years ago, Mitsubishi made it quite easy to program in Instruction List with their "Melsec" software by using "hot-keys" that made it go really fast (much faster than using a visual form of ladder logic). They also made it easy by means of a single key stroke to switch the view of the program between instruction list and ladder logic as there is a one to one correspondence between the two. I do not know if there is a newer version of Melsec that still has that capability.

    Reply

  • I am very interested in reading/writing an article/discussion that goes into the detail on the techniques to writing good ladder logic for things like "sensor back checking, mode and cycle control, step sequences, output logic and fault logic". It also amazes me how many people do not "like" or will not try programming in steps. In my opinion, programs should read like a story. Stepping through sequences is a great way to do that. "Scatter code" drives me nuts. Bandaids on top of bandaids.

    Reply

RSS feed for comments on this page | RSS feed for all comments