By Mike Bacidore, Managing Editor
This is Part 1 of a three-part discussion about what users and developers call higher-level languages and how they vary in performance and suitability. Part II will appear in the November 2008 issue on Control Design and Part III in the December 2008 issue and of ControlDesign.com. To read all three parts please check www.ControlDesign.com/highground.
Ask seven programmers to identify which languages are considered high-level, and you’ll probably get a half-dozen answers. But maybe it’s not a fair question, or at least not a relevant one. While one language might be considered higher-level than another, each has its own trade-offs.
Higher-level languages allow for a quicker development cycle and easier testing of code, but those same advantages can have a slippery slope on the backside.
“Higher-level languages let us do more, and faster,” says James Ingraham, software development team leader at Sage Automation, builder of robot systems in Beaumont, Texas. “There’s literally no program ever written that couldn’t have been written in assembly language. The problem is that it wouldn’t happen. It would take too long, be too difficult and have too many errors. A very famous case is that of the Therac-25 X-ray machine, which delivered lethal overdoses of radiation to several people. That’s a pretty serious software bug.”
The software that controlled the Therac-25, which allegedly gave fatal doses of radiation to three people in the mid-1980s, actually was developed using assembly language, but pieces of the code that controlled versions of the machine dating back to 1972’s Therac-6 model, were continuously reused until the Therac-25’s software included them, but without the hardware interlocks found on previous models. Code reusability, in one form or another, falls under higher-level programming’s list of advantages. And in this case, because of the reused code, the programmer was so removed from the original low-level code that its requirements were forgotten.
And even though most machine builders typically don’t face lethal consequences with a machine malfunction, higher-level languages have a variety of downsides. “One must be careful when using higher-level languages because they can reduce functionality due to the low level of abstraction,” warns Corey McAtee, product manager, Beckhoff Automation (beckhoff.com). “The further you abstract functionality away from the user in order to simplify the language, the more functionality the languages actually lose. Some software programming, such as TwinCat, permit mixed-level language development. Some users find it easier to create applications in ladder because that’s where their comfort zone is. The hope is that, over time, the machine builder sees the benefit of other languages and migrates portions of code to a better-suited language and reduces machine complexity. Mixed-language development environments allow for programmers of different skill levels to develop in the language they are comfortable with. Code library support should be part of the development environment, allowing users to once again use different functions across different levels of languages.”
A key upside to programming with a higher-level language is undoubtedly time savings. Vapo Hydraulics of Dadizele, Belgium, has a customer that manufactures prefab concrete slabs, which need to be dried for 24 hours before they can be taken out of their trays and stored vertically. To save space in the factory, a storage system was built that includes 10 shelves positioned around a central elevator. The concrete at this point is still fluid and needs to be perfectly horizontal. Vapo Hydraulics needed to lift 20-metric-ton unbalanced trays containing uncured concrete more than 6 m, using four hydraulic cylinders while maintaining a strict accuracy of 2 mm.
The Language of Movement
To accurately control the movement, a PID controller needed to continuously adapt to control parameters depending on the shaft position (Figure 1). The operator interface was realized using a touch panel and communicated over Ethernet with the controller, which combines a real-time processor, a reconfigurable field-programmable gate array (FPGA) and industrial I/O modules, all of which were programmed using National Instruments’ LabView graphical programming software.
“We developed this application in just two months,” says Stijn Schacht, head of research and development for Vapo Hydraulics. “Since we developed the software modularly, we can reuse most of the content and adapt the software for new systems within weeks.”
Ask Them in Code
So, what is a higher-level language? Is it graphically represented application logic like LabView, or is it instruction list reused to abstraction?
“Because they enable quicker development and maintenance of application software, higher-level languages such as Microsoft’s Visual Basic or National Instruments’ LabView are often used on PCs to develop test programs and operator interfaces,” explains Steve Nylund, CEO of Delta Computer Systems. “Some applications requiring motion control use a combination of higher-level and lower-level languages. In particular, applications requiring non-standard motion profiles, such as sine or triangle waveforms, and some applications requiring fastest execution speeds or lowest memory usage are often written in lower-level languages. However, implementing all of the motion control algorithms and error-handling in custom code is very tedious and time-consuming, resulting in significant added cost.” A growing number of applications employ both PCs and motion controllers and make use of a mix of higher-level language and machine-specific code on the different platforms, adds Nylund.
“In general, assembly and C are considered low-level,” says Kurt Williams, product manager, National Instruments. “Slightly higher-level languages like C++, Java and .NET add additional abstraction such as object-oriented programming. Still higher-level are languages that further abstract language syntax and intuitively represent application logic graphically. This higher-level representation allows you to focus on solving the application, such as your control algorithm, rather than the mechanics of execution, such as language syntax or hardware-specific functionality. A compiler or execution engine then interprets the higher-level language and generates machine code that performs any necessary hardware-specific operations. The level of abstraction determines how high-level the language is.” All programming languages inherently have some level of abstraction present to make the code human-readable, he says, noting it’s the comparable levels of abstraction that make on language higher-level than another (Figure 2).
State of the Process
Matthew Thornton, product marketing manager, Simatic Engineering Software, at Siemens Energy & Automation, agrees. “In PLC terms, a low-level language could be considered instruction list,” he explains. “This language looks like something similar to machine code. This would be the basis that all other languages are compiled down to. Higher-level languages then would be each language that is built on top of another. Ladder logic is a higher-level language than instruction list is. Being that ladder logic is a graphical language, it is easier to program, understand and troubleshoot than instruction list is. The other IEC 61131 languages are higher-level even than ladder logic. Sequential function chart is a graphical language that helps tremendously in programming sequential type machines. With this language, you simply drag and drop boxes that represent steps of an automation process, assign real-world output signals to each step and assign a transition signal for the code to wait for in each step before moving to the next step. To program a machine this way saves a lot of time compared to programming it in ladder or instruction list. Another IEC language is structured text. This language is more Visual Basic or Pascal-like in nature. It allows you to program complex algorithms, like complex math operations or comparison loops, much more easily than it would be in ladder or instruction list.”
In november: Part II will discuss more issues including portability and usuability of languages, and we’ll hear where one user thinks Java fits in all this.
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.