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.