Higher Ground — Part III

This is the final part of our three-part discussion about what users and developers call higher-level languages and how they vary in performance and suitability. You can find all three parts at www.ControlDesign.com/highground.

The first two parts of this article showed us that using higher-level languages in machine control applications has clear benefits. Some of them have to do with familiarity, some with simplifying the coding process itself.
Higher-level languages also have a big impact on code integration, particularly when third-party software is involved.

Develop, Maintain, Expand

“A higher-level language is a means for programming a computer that provides a level of abstraction over the assembly language level or the machine language level of programming,” explains Dr. Paul James, director, software, at Adept Technology, Livermore Calif. “For us, even C is considered a high-level language. We prefer C, C++ and C# because they give us the power to develop, maintain and expand our software products efficiently. One must leverage third-party software, particularly user interfaces, device drivers and installers, to name a few, and ease of code integration is greatly enhanced with higher-level languages.”

Higher-level languages simplify the coding process for the programmer, explains Keith DeMonia, general manager/chief engineer at Advanced Machine Automation in Birmingham, Ala. “Even simple procedures such as multiplication or testing for equality would take multiple instructions in a low-level language,” he says. “By drastically reducing the code required for common instructions, higher-level languages simplify program development. The biggest drawback to using a high-level language is the inherent inefficiencies associated with simplifying commands. The finished program will typically occupy much more memory and will execute much more slowly. However, technology has all but eliminated this problem in most instances because of the size of memory and speed of today’s CPUs.”

Counterbalancing the potential for execution delays are the efficiencies of interfacing C programming with an operating system on an industrial computer, emphasizes Mike Nikrant, R&D engineer, engineered machines and custom systems group, at Sunnen Products in St. Louis. “The development time to interface to it would be drastically reduced when using a high-level language,” he says. “This is because the operating system is written in C. The majority of the libraries that are available for use are written in a high-level language. Also, some of the real-time operating systems/extensions require the use of a high-level language. They are not available to be written in, for example, assembly language or 61131. One other thing with high-level languages is that they are generally a standard. When you get into the 61131 languages, they are similar from vendor to vendor, but the memory organization is different. With high-level languages, there are ways to reuse code, as well as use the libraries that other people have written.”

As High as High Can Swing to

So, just how high can a language level go, in terms of its abstraction, ease of use and degrees of portability and reusability? As always, it depends on what you want it to do.

“It is important in many automation applications that the programs be maintainable by various people over a long period of time,” explains Steve Nylund, CEO of Delta Computer Systems. “This is why it is so important to choose the correct language for the job. There are many engineers who can program well in a popular lower-level language like C. But when one is asked to work on a C language program originally developed by someone else, it always seems to be difficult. The very flexibility and power of lower-level programs also mean that these programs can be very difficult to maintain, especially if there are not some rules or provisions made for taking care of that.”

Almost on cue, Ben Orchard, application engineer at Opto 22, explains that one of the benefits of flowchart-based programming’s simplicity is the ease with which changes or adjustments can be made to the control strategies. “The more straightforward nature of flowchart-based programming, compared with lower-level and 61131 languages, enables almost anyone to upload the control program, make any desired changes and then download the program back to the controller,” he says. “Not only is this method a time saver, it’s also very empowering for users to be able to make changes on the fly themselves and not have to depend on those who created or are familiar with the program, like the machine builder, to accomplish these tasks.”

But in the U.S. most programming is done in ladder logic, warns Matthew Thornton, product marketing manager, Simatic Engineering Software, at Siemens Energy & Automation. “Although this is considered a higher-level language than instruction list, it is still a low-level language,” he explains. “The reason why ladder logic is most used is because it is what is taught in school and it is what the engineers, maintenance staff and electricians understand in the plant.”

But, once again, is it the language or its function that makes it higher-level? “If a programmer builds an excellent piece of code in ladder logic to program a standard valve, instead of having to reprogram this for each place this valve is used on a machine, it is far more efficient to program it once, save it as a subroutine and then call the subroutine multiple times with different I/O parameters,” explains Thornton. “This reusability can be at the code level, the device level, the station level or the entire machine level. This concept is in itself a higher level of programming.”

Higher-level languages allow a larger set of engineers to solve challenges themselves, says Kurt Williams, product manager, National Instruments. “For example, with LabView, our customers can design the behavior of an entire application in a statechart and then define the execution of each state using the graphical dataflow,” he says. “No program of significant size ever works 100% correctly on first run. A language should encourage modular code development so that individual sections of code can be tested independently. Bugs during development are inevitable, regardless of the language used. The difference comes in how quickly they can be discovered and fixed.”

Whose Application Is It Anyway?

The application typically dictates the level of language needed, but the choice often boils down to the user’s or the programmer’s language preferences. “In control applications that need coordination between many different devices—possibly each device from a different manufacturer using its own specific language—using a high-level language can simplify things,” says John Hayes, senior application engineer at Galil Motion Control. “For instance, in an application that needs to coordinate motion control, I/O and machine vision all at once, it generally makes sense to have a high-level programming language to handle the coordination between these devices. In general, as the complexity of the application increases, the greater the need for a high-level language to be involved.”

Another popular use of high-level languages is supervisory control, says Hayes. “The motion controller or PLC handles the low-level functions of controlling motors and responding to I/O events; however, the high-level language is used to supervise the entire machine,” he explains. “In this way, the high-level language program can start and stop processes that are written using the low-level motion control or PLC language. This combines the benefits of both high-level and low-level programming and is generally a very successful approach to machine control.”

Delta Computer Systems’ RMC firmware and software are written in assembly and C/C++, explains Nylund. “We understand that we can’t expect people to read the code and figure out what is going on, so we have thorough specifications for these programs so that everyone, including the people doing the functionality testing and user documentation, are all on the same page as to exactly what the software is intended to do,” he says. “For systems that are developed and replicated only once or a few times, such as plant automaton or the control of large, specialized machines, there is rarely enough money in the budget to implement all of the systems required to make a program written in lower-level code maintainable by multiple people over a long period of time. Often the only person who can support the program easily is the one who originally wrote it. Most plants choose PLCs and motion controllers for the mission-critical systems. Although internally these are running lower-level programs, the application programs will be done in a more constrictive but easier-to-use and more easily maintainable language.”