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 cant wait, you can find all three parts at www.ControlDesign.com/highground.
Were 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 languages 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. Were 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.
Everybody Must Get Code
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).
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.
Heres 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 Automations Logix systems, I create an integer X, and I dont know or care where it is or how much space it takes up. Thats higher-level. In even older systems, like an SLC-500, all data were separated by type. I couldnt 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.
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.
|Sprechen 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.
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, its reasonably fast, and its quite easy to learn and understand, he explains. Its not perfect, though. Machine control with Java is a sticky point. Its difficult to talk to hardware, and performance can be unpredictable. C# has a lot going for it; basically they learned from Javas mistakes. But its pretty much a Microsoft-only solution, so it has limited appeal to me. Java doesnt 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 isnt 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 wont 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 cant 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 dataintegers, 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 couldnt 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.