Machine design and deployment requires integration of various technologies such as controls, mechanics, vision, lasers, data acquisition, and software, to mention only a few. These mechatronic solutions usually target a specific purpose such as part manufacturing, marking, packaging, etc. Often the controller is a key focus in the design because it must connect and coordinate all of the processes on the machine. Using separate programmable logic controllers (PLCs) and motion controllers necessitates integration, which is costly and time-consuming. Using a single controller for the machine eliminates the need for integration and shortens design and deployment time and cost.Typical machine designs, regardless of the process, include multiple technologies such as mechanics, controls, software, vision, safety, data acquisition, and I/O. As the number of disparate technologies increases, so does the design and deployment time for the machine, especially when software is involved. Why does this happen and what can be done about it? As usual, the answer is a combination of process and tools. As with any design effort, first the requirements of the system must be created and agreed upon. Requirements analysis then ensues, which in part determines the technology necessary to realize the requirements — mechanical solution, software solution, some combination of both, and/or other technologies. With the requirements partitioned, realization of the control and software can begin in detail.
Multiple Controller Architecture
When using multiple controllers for PLC and motion control, the design and deployment is lengthened and very error-prone. The PLC is well-suited for setting up the general sequencing of the machine and managing all of the I/O, interlocks, and communication with the human-machine interface (HMI), but it may not be the best technology for creating motion profiles and interfacing with the motors and drives, which is usually best left to a motion controller. This two-controller architecture requires that a significant volume of information be shared and transferred between the PLC and motion controller. Typically, this means creating a set of tags in the PLC that represents I/O or state information that is to be passed to the motion controller over a standard or proprietary Fieldbus such as EtherCAT, Ethernet/IP, ProfiNET, Modbus TCP, or others. Each of the tags needs to be mapped to a memory address and transferred bidirectionally between the controllers.
This process creates many opportunities for errors, especially as the design progresses and changes are made, or the initial requirements change (as they always do). These errors tend to be difficult to debug and take significant time to correct. In addition, creating libraries of reusable components in disparate development environments is sub-optimal. Finally, the programming language of choice may not be available for members of the team working in different environments, which also tends to increase development time as the learning curve is climbed.
Integrated Automation Solution
A solution to this problem is to use an integrated controller platform that provides programmers with one tag database that is used everywhere in the system, regardless of the programming environment, and is available by name in each of the programming environments. Tools that automatically map the address spaces for the developers and present the programmers with named variables for the tags enable faster design and development of the software, and eliminate headaches as the design progresses or when the system requirements change.
An environment that permits users to program in their language of choice drastically shortens development and debug times, for example, if the overall machine sequencing and interlocks are written in IEC611-31 such as Ladder Diagrams (LD), and the motion code is written in real time .NET or C code and encapsulated as Function Blocks. These motion libraries can be developed, tested, and certified for use as reusable components or POUs (Programmable Operational Units). Then, machine configurations are customized with Ladder Diagram, Function Block Diagram, or Structured Text programming with calls to the library as a standard Function Block. For those that do not prefer .NET or C, library creation using LD, FBD, and ST would be a viable alternative — it provides the same level of software development savings with the tradeoff that some of the routines may run slightly slower than the real-time .NET or C library routines. However, for many applications, this approach would be sufficiently fast.
For those applications using G-code (common in machine-tool applications), the ability to call G code from a LD or the ability to create G-code libraries would be very beneficial and save time. Reuse of code will drastically shorten development and deployment times. In addition to automatically mapping address spaces for the tag, tools that inspect the network for attached I/O and map the I/O to tags automatically can be a big time saver and bug deterrent.
Finally, providing the ability to program the system off-line and simulate the system (without adding any test code) ensures that software can be co-designed with the hardware. This off-line development should also include virtual I/O to be used during off-line programming. This integrated automation approach would reduce programming and commissioning time by 30% to 50%.
This article was contributed by Aerotech, Pittsburgh, PA. For more information, visit http://info.hotims.com/40436-321.