Higher Ground—Part II

High-Level Control Languages Help Speed Development Cycles, but a Preferred Language for Machine Control Hasn’t Emerged

1 of 2 < 1 | 2 View on one page

By Mike Bacidore, Managing Editor

This is Part II of what is now a three-part discussion about what users and developers call higher-level programming languages and how they vary in performance and suitability. After we printed and posted Part I in October, we received so much more user input that we decided to build a third part that will print in December. If you can’t wait, you can find all three parts at www.ControlDesign.com/highground.

We’re learning that higher-level language means different things to different programmers. Allowing for quicker development cycles and easier testing of code can be beneficial, but a higher-level language’s advantages, along with its definition, vary from developer to developer.

Familiarity Breeds Content

At Sunnen Products in St. Louis, C/C++ are the preferred programming languages, primarily because of its developers’ familiarity with them and because C++ is the language of all Microsoft Windows routines.

“A high-level language must be compiled into a machine-readable format, but these types of languages are easier to read and maintain,” explains Mike Nikrant, R&D engineer, engineered machines and custom systems group, at Sunnen. “C and C++ are very similar, and they use the same constructs. The main difference is that C++ is an object-oriented language, where C is not. They both use the same compiler. We’re able to do whatever we need to do in C++, where it would be a lot harder to do in a more machine-level language.”

Code
Everybody Must Get Code
Figure 1: At Sunnen Products, programmers like Mike Nikrant must be able to read the code of another developer, making it easy to reuse the function or change the program flow.
Source: Sunnen

Sunnen also looks at the cost advantages of writing higher-level code. “One of the problems that we see with languages like ladder logic in the code that we write is that the overhead that it takes is very large,” explains Nikrant. “This is due to the scanning of the program that takes place with these languages. With a high-level language, you can just do exactly what you want to do in three lines, instead of having extra variables that would hold a step number to know where you are at.” The other thing, says Nikrant, is that high-level languages are a lot easier to read than low-level languages. “When working on a team of software developers, we need to be able to easily read the code that another developer wrote so that we can use the function possibly for another purpose or make changes to the program flow,” he says (Figure 1).

Application Identification

For James Ingraham, software development team leader at Sage Automation, builder of robot systems in Beaumont, Texas, the main thing a higher-level language must do is insulate the programmer from details that the computer is better at dealing with anyway.

“Here’s an example from the PLC world,” Ingraham offers. “In a Siemens S7-300, if I have an integer X, it goes in the M space, like MW24. If I need a Y, it could go in MW26. I have to pick that. If I mess up and put Y at MW25, it will conflict with X and my data is a mess. I have to remember that a float takes up 4 bytes, not 2, so if X is a float, Y has to start at 28, not 26. In Rockwell Automation’s Logix systems, I create an integer X, and I don’t know or care where it is or how much space it takes up. That’s higher-level. In even older systems, like an SLC-500, all data were separated by type. I couldn’t have something that grouped data into one space. For example, S7 and Logix both have the ability to have a structure that lets me put an integer, a float and a timer in one packet.”

A higher-level language provides a method for encapsulation of code so that it can be easily reused, explains Ron Bliss, product evolution manager, architecture and software, at Rockwell Automation. “The IEC 61131-3 specification uses a physical addressing system that requires the programmer to link instructions to memory that resides in the controller,” he says. “This creates a direct link to the memory organization similar to assembly-language code.”

One of the biggest issues has become one of portability and reuse, continues Bliss. “Because of the link to physical memory, any code that is reused must typically be reworked to change the memory references in order to avoid reference collisions,” he states. “The IEC instruction list language is a classic example of a low-level, second-generation language (2GL). The IEC implementation of structured text is more effective and, in many ways, could classify as a third-generation language (3GL).”

However, continues Bliss, some of the graphical IEC languages like ladder diagram, function block diagram and sequential function chart would classify as fourth-generation languages (4GL). “Yet, the memory-addressing method is still a drawback for the true-to-form IEC 61131-3 implementation,” he adds.

Depending on the applications, portability and reusability can be equally important. “Most low-level languages are written specifically for a certain type of device or microcontroller, which is usually different for each manufacturer,” says John Hayes, senior application engineer at Galil Motion Control. “High-level languages provide portability. A high-level language is compiled down but can run on multiple different hardware platforms. As an example, if you could only run C++ on an Intel motherboard/processor combination, then it would be much more restrictive compared to being able to purchase any brand of motherboard/processor and still be able to run your C++ program.”

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

No one has commented on this page yet.

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