Higher Ground—Part II

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

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.”

Some further restrictions do apply when considering operating system dependence, adds Hayes. “For instance, a C or C++ program can be compiled to run on either Windows or Linux, but a Microsoft Visual Basic program can only be run on a Windows-based machine,” he says.

Advanced Machine Automation in Birmingham, Ala., is one company that has leveraged a Windows-based application to its advantage. It used Visual Basic to create a program that simplifies the HMI and runs a master controller on a thermal friction drilling machine it created (Figure 2). To interface the PC to the Delta Computer Systems motion controller, it uses the RMCLink software package from Delta, which connects with PC software and leverages the Ethernet connection.

“The Visual Basic program incorporated an Excel spreadsheet that contained all the part numbers the customer would run on the machine,” explains Keith DeMonia, general manager/chief engineer at Advanced Machine Automation. “The program acted as the HMI in this application. Visual Basic allowed us to create buttons and lists and easily integrate them with the process of transferring the relevant data from the spreadsheet to the controller. By using a platform familiar to the customer like Excel, they would be able to add parts or modify part data by manipulating the spreadsheet instead of learning about proprietary touchscreen software.”

PC Power
PC POWER
Figure 2: Advanced Machine Automation’s thermal friction drilling machine includes a laptop PC, which serves as the HMI and master controller. It runs a Visual Basic program to control the machine and uses an Excel spreadsheet to maintain recipes containing the drilling parameters corresponding to different part numbers to be manufactured.
Source: Advanced Machine Automation
Obviously, writing proprietary code still maintains an important place in the job description of machine-builder programmers. “If a company has written an application and we want to use the entire application and it will run on our system, we will add the interface to our base application,” says Sunnen’s Nikrant. “In our latest endeavor, we worked with a company and wrote a C++ communication channel between the applications to be able to control the external application, which was also written in C++.”

But portability and reusability are among the big features of higher-level development. “Higher-level languages provide developers with powerful tools for creating complex applications more easily,” says Dr. Paul James, director, software, at robot builder Adept Technology in Livermore, Calif. “Maintainability, portability, extensibility, leveraging third-party code and reusability are all enhanced through proper designs in higher-level languages. Mind you, higher-level languages are not a panacea. One can implement poor software designs regardless of the language, and conversely one can implement excellent software designs in higher- or lower-level languages.”

Part III in the December issue will conclude this discussion with additional user commentary from machine builders including Adept Technology and Advanced Machine Automation, as well as look at the impact of plain old user preference in choosing languages.

Want More
MORE ON CONTROL PLATFORMS

For a list of materials on control platforms, visit www.ControlDesign.com/controlplatforms.

MBFSprechen Sie Python?
Well, maybe not Python, but how do you define a higher-level language? Is it based on how much the programmer is isolated from the actual code? Is it about a more-powerful control capability? Discuss at ControlDesign.com/language.

Java Anybody?

James Ingraham, software development team leader at Sage Automation, is a Java junkie. “The syntax is much cleaner than C++, it runs on virtually any platform, it’s reasonably fast, and it’s quite easy to learn and understand,” he explains. “It’s not perfect, though. Machine control with Java is a sticky point. It’s difficult to talk to hardware, and performance can be unpredictable. C# has a lot going for it; basically they learned from Java’s mistakes. But it’s pretty much a Microsoft-only solution, so it has limited appeal to me. Java doesn’t have pointers, but it can use an interface where C might use a function pointer. And C++ could use a function pointer or a functor. This isn’t possible at all in 61131. Period. There is no way to create a pointer to a function or call a different function based on type data.  An example again: S7-300 will not add an integer and a real.

The function that adds integers won’t take a real, and vice versa. You have to convert to one type and then call the add function for that type. Logix is slightly cleaner; there is only one add function, and it takes integers or reals or one of each. That saves me thinking about the type when all I want to do is add. But I can’t add an integer to a string, or a vector to a vector, or a scalar to a vector. The functionality of Add is fixed at the factory. Compare this with the qsort() sorting function in the C Standard Library. Using function pointers, qsort() will sort an array of any type of data—integers, reals, strings, vectors, widgets, colors, names. When you call qsort(), you give it your data and a pointer to a function that tells qsort() how to compare two things. So the writers of the C Standard Library have given us a function that will compare anything, even things they couldn’t possibly have known about in advance. This gets even easier with the C++ Standard Template Library, and easier still in Java. C has had qsort for more than 20 years.  In more than 10 years, my company has managed to solve every automation challenge thrown at it without actually needing a higher-level language. There have been days I really wanted it though. When we build a palletizing robot, and a customer might have several thousand SKUs, it gets very painful to hand-code sort routines.”