These days, everything from hand soap to candy bars comes in multiple versions. Behind all this variety are smart manufacturing plants that have the ability to collect, move, and package products into multiple formats.
Have it your way
Robots are at the forefront of this packaging trend. But reconfiguring robots to frequently changing requirements can be complex and time-consuming. For starters, line changes on non-homogeneous control systems can require several adjustments across multiple control systems, including machine control, process control, motion, and human-machine interfaces.
A more efficient alternative, however, programmable automation controls (PACs) consolidate discrete, motion, drives and safety control in a single environment, making changeovers easier and significantly faster. What's more, advanced control capabilities within PACs allow for the control of non-linear mechanical systems like articulated arm robots, eliminating the need for a separate controller and software dedicated to robot functions.
First some definitions
In common Cartesian systems, individual motion axes (X, Y, and Z) are controlled to move in linear increments. In contrast, robots consist of multiple rotary motion-control axes oriented in a non-orthogonal fashion. All their axes are coupled, which means that any one movement usually requires some rotation of one or more axes, similar to how the shoulder, elbow, and wrist move in a human arm. This mechanical coupling is the major distinction between robots and programmable Cartesian machines.
The catch is that fully coordinated articulated robots (and other mechanisms consisting of nonorthogonal rotary axes) necessitate complex nonlinear motion that must be programmed in degrees, which is more difficult to envision and code. Kinematic mathematical representation — accounting for robot size, configuration, and the relationship of each axis to the mechanism, including mechanical couplings as a whole — is the basis for this degrees-based coordinate system. It executes on a motion controller, and the coordination is the basis for visualization integration, path movements, and other common robot features.
Traditional kinematics control
Robotic kinematics are usually implemented in one of two ways. Designers can write their own code, and plug it into the controller running the application line. This is a cost-effective way to control simple non-Cartesian robots, but still requires engineering effort to develop equations for transformations, and wrenches engineering resources away from the packaging process itself.
The other way to set up robotic kinematics is to use a standard system to control the process, say a packaging line, and interface it with another dedicated robot controller. Though effective, this approach means that not one but two controllers require hardwiring, separate programming software and languages, cabinets to protect relatively delicate PC-based robot controllers, and integration to tie the robot control to the system handling the packaging application. Too, spare parts and specialized, internal personnel training are par for course.
Because the controllers are linked together using hardwiring or some other physical interface, synchronization is trickier. It takes time for data packets to travel from one processor, over wire, to the next processor, and through a conversion program, and that negatively impacts accuracy. Motion and discrete control can quickly become unsynchronized enough to impact machine performance. Also, synchronizing the exchange of information can eat up to 25% of program logic in each device.
With seperate motion and discrete control, many end users are forced into multiple HMI systems, and maintaining software licenses and expertise for different hardware and software packages, depending on the application size. At a certain point, there's less freedom to customize, and using two controllers can make robots economically impractical for some packaging applications.
Cartesian in, kinematics out
To address some of these challenges, not long ago, integrated systems with one common hardware and software architecture began replacing traditional setups. This spurred development of controllers that eliminate some hardware and programming software by collapsing discrete controllers and motion controllers into one unit. And even newer control platforms with integrated robot control take it one step further: Designers can now additionally control two and three axes of articulated independent and dependent geometries, as well as three axes of selective compliant assembly robot arm (SCARA) geometry.
Central to the design are algorithms that calculate and execute coordinate positions: Designers define precise axis positioning in simple Cartesian coordinates, and then the controller processes and spits out kinematics transformations. Users follow a familiar set of motion instructions to program the robot and the motion components, and system control elements reside on the same hardware chassis, within the same multitasking, multiprocessor architecture. This provides faster communication and data manipulation than that of multiple controllers.
How much faster?
In terms of communication speed, traditional controls with a separate robot PLC will typically use a network interface. The throughput can be measured as the time to execute logic in the PLC, send data to the robot controller and takes some action. And, the same applies in the reverse direction.
As an example, suppose one system's PLC scan time is 5 msec, the time it takes to transfer data to the robot controller is 5 msec, and to read and execute logic is 5 msec. Robot control integrated into a single program — along with the other machine control logic — would in this system eliminate the 5-msec data transfer time and the 5-msec robot logic execution time.
Three axes of independent SCARA geometries can be addressed by leveraging the native articulated independent geometries configuration; related dialogs and motion instructions allow designers to superimpose multiple moves and instructions as needed.
The control system calculates translational and dynamic path profile translation and rotation (orientation) as well as orientation offsets between the two systems. With dynamic rotation, H-Bot gantry robots can be easily controlled, so a single controller manages material handling equipment, processing equipment, and robot.
Users can synchronize their robot's motion with other parts of the application, such as conveyor tracking and vision systems, by superimposing concurrent single and multiple-axis move types and interfacing with off-the-shelf vision systems that can be connected to kinematics-capable controllers via an EtherNet/IP network. (This is useful on applications that need conveyor tracking, for example.) Here, software transforms a specific position from the source coordinate system into the target coordinate system and vice versa, eliminating additional code.
Shared development tools allow for the reuse of engineering resources, and in turn, scalable architecture eliminates repeat work and retraining. Say a plant needs to scale from one line to three. In this case, the house designer needs only to add the necessary processors and copy code from one to the next; programming takes just minutes.
Mixing and mingling
Integrated motion control is the heart of packaging lines, but their eyes and ears are sensors and safety components. Here, integrated kinematics-capable platforms offer another advantage: The ability to use open EtherNet/IP networks to interface with a variety of off-the-shelf third-party vision systems.
Some integrated controls have an open networking strategy to provide a common set of services, enabling users to mix multiple processors, networks, and I/O. For example, from a PC on EtherNet/IP, ControlNet, or DeviceNet, designers can exchange data for fast control, and collect it for trending and analysis. System designers also can route and bridge between networks without additional logic programming for communication.
One control engine and programming environment also means that that the same program developments can be re-deployed across a variety of controller platforms.
For example, safety control added to controllers can include commonality of platform (with the same control engine, motion, networking and I/O) for better sharing of information, reduced training costs, and faster commissioning. Here, safety control is managed just like standard control. Software helps manage safety memory, so users are not required to manually manage the separation of standard and safety memory, or worry about partitioning logic to isolate safety-related data. This coupled with the fact that standard logic and external devices, such as HMIs and other controllers, can read safety memory means that the need to condition safety data from a dedicated safety device is eliminated.
Support for additional geometries
Kinematics-capable controllers are currently limited to three axes of articulated dependent, independent, or SCARA geometries. Soon, however, new controls will also support Delta robots. These products will be released to coincide with that robot's approaching patent expirations: 2006 in Europe, and 2007 in North America.
For more information, call (262) 512-2192 or visit rockwell.com.
Discreet note on discrete
When we talk of discrete motion in this context, we are referring to control with the devices and associated logic of a “typical” PLC: bianary on-off functions, simple analog output, and simple analog input. The programming is typically in ladder diagram. Motion and drive control, on the other hand, involves complex control of positon-and-speed-based devices.
Many outputs, one control
Sigpack (now of Bosch Rexroth Corp., Minneapolis) first built hand-powered machines in 1906 to package chocolate bars, soup, and sugar cubes. Then, it was inconceivable that robots would one day wrap, transport, group, and stack as they do now — with speed and precision that far outperforms humans. But Sigpack robotics do just that in food and medical-product plants everywhere.
On one new packaging line, one of their suction-arm Delta robots takes products from a stationery belt, groups them, and places them on another continuously moving conveyor belt that feeds the next station. Here, besides safety, calibration, and error management, Rockwell Automation's Allen Bradley ControlLogix choreographs all motion, starting where product is fed into the grouping unit.
The track layout is designed to work around several limitations: that workspace available to the robot is limited, that the robot's mechanical stress limits must not be exceeded, and that acceleration of some products must be kept to a minimum. So, the controller calculates blending radii for smooth transitions from one movement to the next. Allowing for gravity, various acceleration values for vertical and horizontal moves can also be selected to optimize cell performance. Memory management works with tags rather than encrypted addresses. Sometimes this addressing is not only included in the programming software, but also stored in the control memory, to simplify communication with both decentralized field equipment and higher-level monitoring and visualization systems.
Pick-and-place is no easy task for any robot, as product position can vary, and (on a moving belt with variable speed) place position differs from the theoretical position. So tracking in the robot control compensates by summing the two vectors to determine the required movement for the actual situation.
A gatekeeper function automatically monitors cavities in the robot's work area. If a cavity leaves the work area and is only partially filled (or is emptied, or not filled at all) the gatekeeper blocks the corresponding feeder. In this way the robot always has sufficient time to complete work on a cavity. A set parameter indicates how far down the robot's work area an empty cavity can travel before a stop command is activated.
Here, the robot kinematics include forwards and backward transformations: Backward transformations calculate the appropriate angle for actual robot axes using universal X, Y, and Z coordinates. By means of forward transformation, joint positions are converted into universal coordinates.
Programming follows IEC 61131-3 (LAD, FBD, ST, SFC) with a multitasking OS symbol-based CPU. With some simple address mapping, TAG aliasing allows reuse of existing programs over several projects — and even the mapping is straightforward, because the RSLogix 5000 controller automatically identifies which tags do not have actual I/O addresses.