Programming With Old and New

Innovations Supplement Older Technology. Programs Today Consist of Object-Based Software. Is This the End of Legacy Programming Languages?

By Jim Montague

Perhaps it's because we're such a win-loss, black-and-white culture, but it seems like each new technology is supposed to defeat and replace the one before it. In reality, many innovations simply supplement older, tried-and-true tools, and this scenario seems to be true for object-based programming. Of course, programmers who used to write code eventually developed libraries of reusable software function blocks, which were linked by software-based interface connections into flowchart-type programs. In fact, many programs now consist almost entirely of object-based software, but has this meant the end of legacy programming languages? No way.

"Though their code is more verbose at first, object-based programs are cleaner, and make it easier to find bugs and see where changes need to be made," says Bob Trask, senior electrical engineer at Beckhoff Automation. "These function blocks also have code that's easily copied, but it was too easy to rewrite some of the operating data and mess with the code, and this could make it hard to isolate bugs and avoid version difficulties. Meanwhile, a block for a conveyor drive's on/off and speed could be reused 10 times in a plant, for example, but many other parameters still had to be reentered every time. More recently, the third revision to the IEC 61131-3 standard has helped provide object extensions to the existing software framework of how function blocks are handled, so copies can inherit needed functions, while code that shouldn't be changed can be isolated and encapsulated." These object extensions are a key part of Beckhoff's just-released TwinCat 3 software.

We'll see more visual programming mash-ups of different programming approaches, so users can apply the best software for each task.

Ironically, the inheritance and encapsulation capabilities provided by IEC 61131-3 also enable object-based software to help integrate and reapply software from different legacy programs. "Some programming languages are better than others for particular tasks," Trask adds. "If you're doing a lot of math, ladder logic is inherently more cumbersome, so structured text is better because it's like writing calculations in text. However, if you're doing discrete functions, like closing doors before starting up a machine, then ladder is better because its symbols are easier to see. But ladder's rungs are static and can't be shifted easily, so we're also using more continuous function chart programming, which allows easier shifting of instruction blocks and editing."

One of the most interesting trends in object-based programming is that it enables more "under the hood," so users don't have to deal with as many low-level details, according to Richard McDonell, strategic marketing director for the Americas at National Instruments (NI). "It helps users abstract and simplify applications they're trying to install, and it supports our field-programmable gate arrays (FPGAs) and multi-core computing systems."

Sometimes users need to combine text-based and graphical programming, McDonell adds. NI's LabView software allows text-based programming to appear side-by-side with graphical code so that users don't have to throw away their investments in programming and equipment.

"In the future, we'll see more visual programming mash-ups of different programming approaches, so users can apply the best software for each task," McDonell says.

Likewise, B&R Automation reports that its latest Automation Studio software supports object-based programming with a seamless add-on for C++ code, so users can mix in machine sections with programs written in ladder or structured text, such as state machine functions or simple I/O functions.

"It's just easier to solve some problems in structured text or C, such as performing some recipes or implementing a photo cell," says Stephan Stricker, B&R's product manager. "The problem with function blocks was they weren't very flexible, and so they were hard to reuse because users always needed slight variations for their applications. This is why it was so important for object-based programs to gain inherit and override functions, so the main object framework could handle start/stop, power and homing tasks, but users could override others as needed. Now, a user can gain huge benefits by creating an object framework in C++, and then arranging static blocks or doing ladder within it when it's most useful."

Join the discussion

We welcome your thoughtful comments. Please comply with our Community rules.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

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