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.
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.
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. It's really the programmer who sets the program architecture, and this is where improvements can really be made. A well-written and simple ladder-diagram program includes sensor back checking, mode and cycle control, step sequences, output logic and fault logic at a minimum. Keeping these functional blocks of code separate is a good starting point. Let me know if you are interested, and we can expand greatly on these techniques.
The key here is the ladder-diagram step sequence. When a program is written, started up and run for a year before anyone touches it again, there is nothing better than ladder diagram and a well-written and documented step sequence to quickly understand program function. Reading through the coil descriptors in the ladder-diagram step sequence should read like a sequence of operation. The steps define the operation chronologically and display the condition of the logic graphically.
When there is a problem or an enhancement needed, the new guy can get up to speed quickly and not have to wade through multiple programming languages. If you don't do it every day, simpler is better. Opening a program and finding the main step-sequence ladder diagram, the programmer, technician or maintenance personnel can understand what's going on with the equipment with little study or review needed. While you are at it writing a great step sequence in ladder diagram, be sure to consider ways to make it reusable code, but that's a subject of another column.
Homepage image by Nuno Nogueira (w:User:Nmnogueira) (Own work) [CC BY-SA 2.5 (http://creativecommons.org/licenses/by-sa/2.5)], via Wikimedia Commons
