In the beginning, machine and robot builder OEMs developing an automation system had the choice of relay ladder logic for PLCs, and assembly language for single-board computers and minicomputers. Though PLC logic was simple and straightforward, vintage PLCs had little computing capacity. If complex control or data handling was needed, a computer was required.
Writing control programs on a computer was tedious, with programmers immersed in every aspect from interrupt handling to writing real-time operating systems to developing PID algorithms. It was done in assembly language, on computers that sometimes had only 16K words of memory, and with little or no support from the computer vendor for real-time control applications.
Automation hardware and software have come a long way since then, but so have machine and robot applications. Today, machine and robot control programmers might have to deal with very high-speed control and synchronization, complex motion, vision systems, networks, animated HMIs, multi-touch panels, remote access, communications to higher-level computing systems, and more. Further, OEMs often have to program these advanced machines and robots in mere weeks.
This creates a software development bottleneck for many OEMs, with that activity often being the task that constrains delivery schedules. Fortunately, a solution is at hand, namely the use of modular software to create custom machines and robots.
Modules Speed Development
Builders program their products using modular software, thereby creating custom controller and HMI programs from standard blocks of code. This allows OEMs to quickly and reliably produce the different variants of machines and robots demanded by their customers.
When customers demand highly customized features, machine builders often can program these internally, or they can acquire specialized blocks of code from suppliers or other sources. In the future, expect peripheral components on production lines such as robots to come with their own modular software that can be dragged and dropped into the OEMs' programming environment. When OEMs create software by these means, the end product is more standardized and easier to modify and support, both by the builders and their customers.
Modular code benefits machine and robot builders, system integrators and end users. For example, D&V Electronics in Woodbridge, Ontario, builds equipment that tests a variety of automotive starter, alternator and electric motors. Like most machine builders, the company has basic hardware and software modules that can be put together quickly to produce custom test systems. "Each iteration of a new tester builds upon previously written code, so it shortens development time substantially," says Ciprian Baciou, engineer at D&V.
Jason Conner, principal engineer at Concept Systems, a system integrator in Albany, Ore., uses modular software as building blocks. "It's less expensive for Concept Systems because code reuse eliminates greenfield programming, which is generally very time-intensive," Conner explains. "An engineer can choose from a library of code, and either use the code out of the box or build upon it with the knowledge that the code already has been well-tested and proven within a production environment."
Modular software also helps skid builders meet the needs of end users. Matt Bothe is a senior process controls engineer at MC Polymers, a producer of styrene-butadiene in Charlotte, N.C. His company often purchases process skids, and he prefers modular programming. "Modular programming for conventional utility systems benefits end users like us through reduced installation costs, available support, reliable operations, consistent performance, and facilitated troubleshooting," Bothe notes. "Particularly in the batch world, modular programming has proven to be significantly superior in programmability, efficiency, portability and troubleshooting to the alternatives, such as custom algorithms with little if any standardized structure and terminology."
Developing Modular Code
As noted, we've come a long way from when ladder logic and assembly language were the only programming options. Today, programmers deal with terminology unheard of 30 years ago: object-oriented programming (OOP), layers of abstraction, encapsulation, function blocks, inheritance, class deviation, polymorphism and modeling. Space doesn't permit a discussion of all these modern programming methods, but it's clear that OEMs use all of these methods and more with great success.
"Concept Systems uses a wide range of software for providing solutions to our customers," Conner notes. "The solutions could use many different software platforms, ranging from simple ladder logic to more-complex, object-oriented C++. Each platform has its own breadth of modularity, but we always use whatever capabilities are available within the software package to implement modular and reusable code. For example, with PLC-based applications, we'll employ user-defined types and device-specific routines to make our PLC code capable of being constructed as building blocks. With custom software development, we use object-oriented techniques to allow for reuse, unit testing, and clean structured code."
"D&V Electronics Builds Machines for Flexible Testing," "Modular Material Handling" and "Modular HMI Software" articles illustrate how OEMs are using different languages, including structured text, flowcharts and ladder logic.
Some machine builders stick with tried-and-true approaches, while others dabble in more esoteric approaches. "Machines and systems normally are programmed using procedural programming languages," explains Robert Muehlfellner, director of automation technology at B&R Industrial Automation. "This type of programming has proven itself for years and will surely continue to be used by many OEMs. In some situations, however, it makes sense to question its use and examine whether other solutions such as object-oriented programming are a better fit. OOP encapsulates machine software into clear functional modular units which are solely responsible for handling a task. These units make it very easy to reuse the code. All the necessary functions and data responsible for handling a particular task are included."
There's no question that OOP is a good fit for modular programming, says Bob Trask, TwinCAT 3 specialist at Beckhoff Automation. "We're entering an era in automation that allows increased software complexity without sacrificing reliability," he says. "A major benefit of IEC 61131-3 is the ability to use object-oriented concepts in control languages. OOP is an absolutely proven approach."
Programmers are used to a program starting at the top and executing all the code one line or one rung at a time and starting over, Trask explains. "The more extensive this code gets, the more perilous and unstable it becomes. Object-oriented, modular thinking encourages us to break things up into objects and define the interface between those objects. This helps keep code isolated, which is what the computer industry calls abstraction."
OOP seems to be widely accepted among vendors. "OOP allows a user to keep track of where their data is during program execution," notes Dan Fenton, control and software product marketing specialist at Phoenix Contact. "Concepts such as encapsulation and abstraction allow programmers to reduce complex code to simple blocks with inputs and outputs. This allows an advanced programmer creating a custom PID loop or complex math to pass code between programs without making a mistake in the rewrite of the algorithm."
The machine builders' customers can add and subtract features as they see fit during the course of a series of projects, he adds. "Together with a well-built version control system for their code, modular software is a powerful tool."
Vendors Supply Code
Another big advancement in programming comes from vendors that now supply modular software code such as device drivers, communications interfaces, and software support packages that encourage OEMs to build code libraries. That's a pretty smart move, because if an OEM gets used to using a vendor's software modules, it tends to "lock them in" for future applications.
Sam Vandiver, project manager at Brown Engineers in Little Rock, Ark., uses modular software that Brown develops itself, and code it gets from its vendor. "We develop and implement critical monitoring solutions primarily targeting emergency standby generators and related power system components," Vandiver explains. "Our modular design approach is evident at several levels. At the top level, the CoDeSys programming interface we use allows development in any of the four languages specified by IEC 61131. At the next level, we use functions developed by Wago, our PLC vendor. They furnish code libraries that provide functionality such as TCP, UDP, Modbus serial, Modbus TCP, HTTP, FTP, SNMP, SNTP and other PLC-specific functions — all of which greatly accelerate our time-to-market. In addition, we believe these libraries are more thoroughly tested in a variety of conditions than would be possible if we wrote and maintained our own libraries."
Vandiver is enthusiastic about the idea. "By using modular design techniques, our customers receive cumulative benefits from the efforts of an international standards organization, a PLC manufacturer and software developer, and a solution provider," he states. "What a deal!"
Brown Engineers uses modules from one vendor, but others use software from various suppliers.
InduSoft supplies HMI software to machine builders, and it has its own niche in the modular software equation — where machines and robots need to interface to higher-level software.
"InduSoft Web Studio is designed with the concept of layers of abstraction," explains Fabio Terezinho, vice president of consulting services for InduSoft. "The idea is to allow the user to build an HMI solution in blocks or modules that can be integrated and reused in a simple and timely manner. OEMs can build applications with InduSoft Web Studio and run them on any Microsoft platform, from Windows CE to Windows 8, without having to recompile or redesign the application. They can configure ERP integration rules, transactions and even redundancy regardless of the specific database engine used, including MS SQL Server, Oracle, Sybase and OSIsoft PI."