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."