Consumer-goods and food-production companies employ controls experts trained to manage complex factory-communications networks. As these companies seek wider adoption of robotics within picking, packing, and palletizing (3P)—at the expense of hard-automation lines—robots must be able to communicate easily and effectively within existing networks.

Allowing robots to take their commands from a programmable automation controller (PAC) rather than their own unique and proprietary control platform would allow robots in 3P applications to be embedded in the manufacturing controls rather than integrated to the controls.

Why embedded is better

For process-specific robotic applications, such as welding or painting, we want standard robots with their own proprietary controls and application-specific software. They exist in a larger manufacturing context and are integrated with control networks, but do their own thing for the most part. The controller firmware contains a wealth of process-specific information—for example, algorithms designed to optimize the arc-welding process to ensure smooth arc starts and minimize spatter. Internal control also keeps more processing overhead from being loaded onto the larger system.

Robots designed for these applications can be purchased with much of this process-specific programming built in, or chosen from libraries of applications. This helps get up and running faster, but such specialized programming is something of a black box to most engineers in the field who have not had specific training. They have little opportunity to understand what’s happening under the covers, but in most cases with those types of applications that isn’t really a problem.

Robots in more applications

In the consumer-goods and food-processing markets, most robots work in material-handling tasks such as assembly, packaging, and palletizing. Here, the integration process of marrying the robot controller to the rest of the workcell creates challenges and adds cost and time to the startup process.

In a recent announcement, Robotic Industries Association president Jeff Burnstein said he expects continued growth in the material-handling sector. “Material handling is important to just about every industry, and robots are reaching new users all the time,” he said.

The teams charged with installing, integrating, and managing these robots on a daily basis must have a great deal of robotics expertise. That is not a typical skill set often found in consumer-goods and food-processing plants. If the engineer overseeing the workcell does not have sufficient robotic experience, it can be difficult to optimize the installation in the context of the larger manufacturing line, and the ultimate result may never be entirely satisfactory.

For robot manufacturers to tap into that vast and growing material-handling arena, robot OEMs have two choices: Train more robot experts for these new markets, or recognize that industry is already flush with well-trained PAC experts, and leverage that knowledge base and develop technology that allows PAC/PLC experts to program and manage our robots.

A coming-out party

One such collaboration of expertise was displayed at the 2010 Pack Expo in Chicago in October 2010. A solution was demonstrated that allowed robot control and programming directly from a PAC, in this case, a Rockwell Automation ControlLogix PAC platform. The result is that users can now program, deploy, and support robotic-system solutions using their existing in-house PAC/PLC expertise.

While those at Pack Expo saw the implications for packaging and palletizing automation solutions, the technology applies anywhere automation is used to handle materials in place of robotics. In the consumer-goods or food-processing industries, the process expertise from the robot controller becomes unnecessary since the applications don’t require it. Lifting a jug off a conveyor and placing it in a carton does not demand the level of sophisticated process control that welding stainless-steel pipe fittings does. Users can eschew the robot controller and use software for robot control.

Robot OEMs are taking different approaches to achieve the same goal: robot control via PACs. For example, one robot OEM at Pack Expo showcased technology that allows its robots to run directly from the PAC using Rockwell’s Kinematics software.

Developed over the past several years, the software allows the end user to eliminate additional motion and safety controllers, software, and any special technology needed for integrating robots into specific applications. Data moves directly from the PLC to the drives connected to the robot.

More control

Yaskawa’s Motoman Robotics Division displayed a solution that allows control of up to 15 axes, and the ability to direct all of the robots in the Motoman lineup. The gateway resides within the PLC backplane and acts as a coprocessor on which Motoman runs its own kinematics software. Motoman configured its Sigma5 drives to communicate over EtherCAT, allowing the drives to enunciate their status. The gateway replaces the robot controller’s upper-level CPU, where kinematic software would typically run. Now, anyone in the plant with RSLogix expertise can keep the robots in production. You no longer need a robot programmer in house.

Using this approach, programming for a robot is not difficult, but may require some practice. From a technical standpoint, it uses the same type of ladder logic. When the robot needs to do something, the programmer adds that instruction to the sequence. If you’ve been writing programs for linear actuators, other types of mechanisms, and motion control, it isn’t much different.

However, it does require more complex thinking. That linear actuator doesn’t have a very long list of possible moves. It can go in or out and stop at various points in between. A robot, on the other hand, has many possibilities. The programmer has to think about several axes of motion at the same time. Determining what has to happen from a specific movement standpoint on each axis is often a greater challenge than inserting the appropriate instructions into the program. Dealing with “kinematically interesting” motion requires a certain level of creativity, but the actual programming is manageable.

Benefits start on day one, and keep coming

The advantages of being able to modify your own programming become clear. On such a project, a controls engineer simply calls up his PAC programming software, drops in the required add-on instructions, and the system is ready to program and run.

The benefits of PAC-controlled robots come from the very start of an automation project and continue with everyday use. From the beginning, users experience more vertical project launches—quicker startup from the time the equipment hits the dock to when it’s running in full production.

What typically slows the launch process down? Integration and debugging. Using a standard PAC allows this process to occur before the equipment ever leaves the OEM. During the design process, the user can give application data to the OEM, which can be used to simulate the environment and view the robot in action on a PC. The user can then tweak the data as necessary. These tools all lead to very tight synchronization of robot motion to peripheral I/O such as sensors and conveyors. The result is that system integration becomes little more than machine building, carving weeks off of the launch cycle.

Improved diagnostics and data security

Once the robotic-automation system is up and running in a production environment, such as on an assembly or packaging line, the immediate benefit of adding robotic flexibility is easy to see. A hard-automation solution is much more difficult to change should circumstances require it, since the hardware and software typically have less allowance for modification. With a robot, a controls engineer can use the PAC to reprogram the action with a new motion profile for a new task. Upgrades can be made at run time without stopping the application.

Another clear benefit of the PAC platform is faster and simpler diagnostics, compared to hard automation. The end user can apply trending tools and diagnostics to the robots to identify and analyze problems quickly, reducing downtime required for maintenance. For example, in the case of RS Logix the controls engineer can monitor torque on each drive over time, identify any out-of-tolerance conditions, and schedule a replacement before failure. Robot uptime is optimized as a result of scheduled maintenance rather than unscheduled failure.

With a separate robot controller and PLC, in the event of a system failure such as an electrical outage, it can be difficult to ensure that the robot memory backup is synchronized to the backup of the PLC. If an outage causes a loss of memory, the end user often can’t be sure that he has the most current version of the robot backup and the PLC backup. This concern has been eliminated with the PAC running the whole show.

The material-handling market within consumer goods and food manufacturing is poised for growth. As companies long for automation along assembly, packaging, and similar production lines, they want to implement it without the costs and rigidity of hard automation. Now they have a new option: PAC-controlled robots, which promise to bring flexible automation into manufacturing in a huge way.

Erik Nieves is technology director for Yaskawa Motoman Robotics.

ONLINE:

For more information, visit:

www.motoman.com

http://robotics.org

www.rockwellautomation.com

Also read Recycling Robots, Applied Automation, September 2010.