I'M WHAT SOME of your articles have referred to as a “bit banger.” I’m a PLC ladder logic guy who knows he needs to get more current. I need a grounded understanding of what advantages I can get from becoming functional in object-based programming. I know reusability is a big plus, but can a few of you summarize its major advantages? How hard is it to learn, by comparison? Any downsides?
– From August 2005 Control Design
ANSWERS:
Not Sure I Get It
I, too, am a ladder person, but the rest of the world does things differently. I don’t see block programming as efficient regarding scan times. My experience is that the push for higher machine speeds could be a problem for the PLC. I looked at a foreign PLC program that I downloaded onto my computer. The only thing I saw was the ladder logic and I think it originally was in object form. It was very confusing and in my opinion not efficient. A programmer might see an input point in a rung a couple of times like I did. If done too much the scan time will go up.
This question reminds me of machine language vs. structured programming. If the program gets too complicated, the program would be hard to follow in machine language. However, if the ladder PLC program can be broken up into subroutines, the overall program has a good chance of having a shorter scan time.
I haven’t programmed in block language, but I can see it advantages and disadvantages.
Don A Klinger, Marvel Manufacturing Co., Oshkosh, Wis.
Focus on Key Benefits
The usefulness of object-based programming to PLC developers is a longstanding question, particularly given the large investment necessary to become fluent with object-based development concepts. Until the IEC 61131-3 standard was established, object-based programming hasn’t been particularly beneficial to the overall PLC population. The standard, which provides guidelines for well-structured PLC software development, puts strong emphasis on the concept of function blocks. Based on some basic concepts from object-based development, function blocks provide a method to package part of a control program, and describe both the data structure and the data algorithm or behavior.
Function blocks are useful as a way to easily reuse code in different parts of one program or in different projects. Also, using function blocks encourages a well-defined software structure, whether it’s from the top-down or bottom-up, which ultimately will result in better code and conceptually, faster development. Because the IEC standard also includes block interface definition, any function block, no matter who its developer is, will be easily integrated into any application, opening the door for non-vendor-defined libraries of function blocks that will run on any platform.
Becoming familiar with the basic concepts of object-based development certainly will allow you to introduce function block development into your projects and effectively leverage this new concept, without a massive time investment.
That being said, the field of object-based development is enormous, with many intricacies that don’t transfer to function blocks. For example, while the concepts of data encapsulation and methods are crucial to function-block development, polymorphism and inheritance, two powerful features of object-based development, aren’t currently part of the IEC 61131-3 function block definition. Spending the time necessary to conquer the entire object-based programming paradigm, while an excellent academic exercise, would be wasteful from the PLC-development perspective. Focus rather on key concepts, such as software encapsulation, user-defined type development and method implementation, and you’ll see a solid return on your investment. Looking to the future, as adoption of IEC 61131-3 grows, your familiarity with object-based design basics will continue to prove useful.
However, there are limits to object-based development, and therefore to function blocks, which are a concern for those developing large, distributed systems. Object abstraction, the concept of encapsulating data and algorithm into one portable object, doesn’t account for execution concurrency in a system, or allow for any timing specification. Precise control of code execution and timing between distributed nodes is vital, and this limitation, which can be overcome with hardware timing connections, will prove problematic for some users today and for many more in the future.
In addition, actor-based development, an established approach in which individual code pieces execute independently—often through a dataflow paradigm—and communicate via asynchronous events, features the same reuse, program architecture and rapid development benefits of object-based programming. Actor-based development also meets the needs of those that require execution concurrency and software timing control. As the number of large-scale applications requiring better distributed intelligence increases in the industrial control market, look for greater adoption of actor-based language.
Greg Wempe, product manager, industrial automation and control software, National Instruments, Austin, Texas
You’ll Never Go Back
The concept of function blocks is paramount in code reuse. Good project code developers will develop generic function blocks, and reuse them over and over. Within the IEC 61131-3 environment, they act as completely separate entities. If a change needs to be made to basic behavior, only the original function block is changed and is inherently updated for all instances, or occurrences, of the function block in your code.
There are no downsides to learning object-based programming. It is the future. I can honestly say that 100% of the former "bit bangers" I have the opportunity to educate never look back once they get it. Not 80%, not 90%. One hundred percent leave ladder-only-based PLCs behind forever. It is much easier in the long run. Really. With regard to the structured text language, one student once quipped, "It is how you talk". For example:
- IF Temperature > 100 THEN
- TurnSomethingOff;
- END_IF
Sure, there are a few syntax rules to remember and use, which can cause initial frustration. The rules, however, are easy, repeatable, and learned within hours. It’s a small price to pay for a lifetime of making your life simpler, less stressful, and—guess what?—there’s an extra added bonus: you will be able to do many things you had only wished you could do before.
With the right package and enough processor (any PC these days), you can do your sequential logic and your motion logic all in the same place. Awesome.
Robert Trask, PE, Beckhoff Automation, Carlsbad, Calif.
It’s an Important New Skill
Anytime you can abstract the process by “objectifying” the control platform, lots of people win. Yes, you should learn anything and everything new. Being prepared is one of the best defenses against obsolescence.
Definitions might be a bit varied, however. OOP (object-oriented programming) was coined by Borland, I think, so it’s a computer language term, which has been migrated to industrial programming languages such as IEC-61131-style programming environments.
A subroutine in a PLC can be reused, but the main difference in reusability is that the addressing must be different than anything else. Objects typically are named. Variables then have a property that is their name, and, thus, the variable is an object. Many objects exist with many methods, properties, and events associated with them. These are vendor-defined as such. IEC-style environments provide a portion of these, but by no means all of them.
If you’ve programmed with most any HMI software, then you’ve already used an object environment. Migrating to control programming won't be too tough, but it is a must to do so.
The big advantage I see with OOP in a control environment is that you’ll be able to work with more control systems. Job security is a good thing. There is no downside except for the added time required to assimilate the differences. Once you learn a programming method that allows you to make an object of a device control sequence, it allows everyone to see the connected I/O, the associated data values, the underlying control code, and the connectivity with the rest of the process. That, in turn, makes it easy to design, develop, implement, and maintain. It is a different mindset but not hard to overcome.
Jeremy Pollard, managing director, PLCopen North America
February’s Problem
What Are Critical E-CAD Features?
We’re expanding out of panel building into more complex machine control builds. With fresh ownership, we’re encouraged to upgrade from a really old and basic electrical schematic software to a more integrated tool set. I don’t want a bunch of vendor product noise right now, but I’d like to hear from users about the important functions to look for in a good electrical CAD program including how to judge databases, training requirements, upgrades, and support.
Send us your comments, suggestions, or solutions for this problem. We’ll include them in the February 2006 issue and post in on ControlDesign.com. Send visuals, too—a sketch is fine. E-mail us at [email protected] or mail to The Answer to Your Problems, CONTROL DESIGN, 555 W. Pierce Rd., Suite 301, Itasca, IL 60143. You can also fax to 630/467-1124. Please include your company, location and title in the response. Have a problem you’d like to pose to the readers? Send it along, too.
