Bringing Robotics and Motion Control Together

If you’ve ever run an organization, you know that getting people to work together is the hardest part.  When it comes to machine controls, it’s no different. Controlling axes is only half the battle - integrating the motion controller with robot controllers presents a far bigger challenge. Integrators find themselves adding cabling, writing hundreds of lines of code, racking up engineering hours to get things working together while running the risk of not achieving the performance they seek. One alternative is to run both motion axes and robotics through the same controller. Is it a viable approach in today’s environment? How and when is it appropriate?

Robotics is not merely for applications like welding in automotive applications.  The technology crops up all over the place, from palletizing product in packaging lines to performing pick-and-place operations in electronics fabs.  Such designs require the machine controller to interface with the robot controller.  That’s a job far more easily said than done. The problem is rooted in the fact that most robotic solutions feature proprietary hardware and software.  That can make the task of integrating a robot controller with a line controller difficult.

“A robot from manufacturer A and a robot from manufacturer B have different ways of parameterizing things,” says Gerry Wootton, Staff Scientist at system integrator ATS Automation Tooling Systems (Cambridge, Ontario, Canada).  “They have different internal programming languages, different command and control sequences and so on.”

“Part of our advantage over our competitors is we design the servo motors ourselves so they behave a certain way on our robot,” says Bob Rochelle, Sales Manager at Kawasaki Robotics (USA) Inc. (Wixom, Michigan).  “Our controller is built to control that servo motor and that one specification.”  Kawasaki is not alone; every robotic arm has its idiosyncrasies.

The primary benefits that robotics offers is the cost and time savings of a bundled offering.  Rather than paying for five or six axes of motion control, the user can purchase a single robot arm fitted with an integrated controller featuring a full suite of capabilities.  For a basic application, a robot arm can significantly save integration time. Not every application is basic, however, and those requiring more precision can present challenges.  “It's not as though these bundled architectures can solve all your problems,” says Wootton.  “At an integration level you still spend a lot of time working on issues of dynamics and stability and you are limited in what you can accomplish because it’s a closed environment.”

Like most other hardware in the automation world, the capabilities of robot controllers have been steadily increasing.  Today, they may offer ladder-logic programming and additional I/O ports. One way to simplify the interface problem is to let the robot controller run the motion axes.  This approach might be effective in the case of a handful of ancillary axes, for example in a robot welding cell with one or more stainless steel turntables.  In today's factory automation environment, however, even a simple station might have to interact with motion and vision and sensors, as well as performing shopfloor-to-top floor communications such as interfacing with SQL databases or process management tools. “You don't have to get to a terribly complicated application before you need to integrate robot motion and other motion together in one control architecture,” says Wootton.

Power to the PLC
If a robot controller running motion axes isn’t sufficient to meet performance requires, the problem can also be attacked from the other direction, using a programmable logic controller (PLC) or programmable automation controller (PAC) to integrate multiple control tasks, including motion axes, robotics, machine vision, sensors, safety, and more. “There are certain applications like packaging, for example, where the robot is an integral part of the line,” says Robert Hirschinger, Product Marketing Manager at Rockwell Automation.  “In those applications, often times we have overall line control so we’re controlling a number of axes on the machine, we’re doing the I/O, the networking, the safety support, so in those types of machine configurations there’s a natural tendency to say, ‘Okay, let's go to the next step and actually control the in-line robots.’”

Don't Miss These Industry-Leading Events!

October 1-3, 2024
Cincinnati, OH

October 7, 2024
Memphis, TN

October 8-10, 2024
Memphis, TN

November 12-13, 2024
Atlanta, GA

A number of PLC/PAC platforms from various suppliers offer these capabilities.  The approach can speed integration and provide cost savings. Because of robot-to-robot variation, however, the approach can really only be executed successfully when the robot arm integrates the motor/drive combinations from the PLC manufacturer.  Like the robot manufacturers, they know their product parameters and have developed a controls product designed to work with it.  The systems are effective, as long as the user and integrator don’t object to the constraint.

Unified control architectures
On the face of it, the idea of a universal controller is an appealing one for end users and integrators alike.  The greater the degree of commonality in the controls architecture, the smaller the knowledge base an integrator must maintain.  Instead of knowing the controls structures of 25 different robot controllers, for example, they only need to know a few.

“As a large integrator, we want to work on a common platform that everybody knows and understands,” says Wootton.  “We don't want to say, ‘Oh, we’ll have to wait until Fred comes back from Hong Kong because he's the only guy who knows how to work with that robot.’  That's not really a very desirable frame for us to be in.

Unified control is a smart idea in theory but the reality can be much more challenging. One of the obstacles is the closed nature of the solution.  Different manufacturers may use different programming languages, as well as different motion control paradigms and state engines. “As soon as you try to integrate into larger controls architecture, you usually end up having to write a whole lot of code to mimic and track the behavior of individual robot control architectures,” says Wooten.  “Because [the robot] comes with a bundled package, there are a lot of things you have to find out the hard way like the capabilities of the actuators, the details of the encoder technology, circuit protection, current limiting, a whole range of stuff that you don’t have any real access to.  You have to essentially reverse engineer the kinematics of the device because there's no easy way to get your hands on that.  Often there is hidden or embedded dynamic information such as factory calibration data and other parameters.”

Even something as simple as a motor parameter can cause problems.  “Say our servos run at 300 V and somebody else's are at 150 V,” says Rochelle.  “If you send 300 V to 150 V motor you get smoke.  Making a universal controller would be more trouble than it’s worth for [integrators].”

The future of unified control
A truly unified control scheme would require some type of open standard, which would force manufacturers to expose the properties of their devices or even abandon some of their differentiators.  Given the competitive climate of the robotics market, in particular, that may not be likely to happen any time soon.

Even compatibility at the command and control level would be an advantage.  With a unified communications protocol and standardized device profile, integrators and OEM machine builders could swap out different robots and to the master controller they’d all look the same as far as interfaces, behavior, data frames, etc.  Such a scenario would require a significant standardization effort, though, which is never easy or quick in a situation with so many stakeholders.

For now, it appears that engineers who need to combine robotics capabilities with tightly synchronized motion has the choice of working within a proprietary environment - letting the robot control the motion or the PLC control the robot - or striking out on their own to build an integrated system with a limited knowledge base.  The latter case may offer them additional flexibility and performance but it comes at the cost of engineering hours.

“It’s very painful,” says Wootton. “We’ve done it in a few cases.  We’ve demonstrated that we can improve the performance significantly by replacing the bundled controller with a more open and general controls platform but it really isn’t worth it to go that way.  I think the real issue is more to have a unified communications network for motion control and standard state diagrams for all of your axis controls and common data frames for all the properties that you’re dealing with.  Then you could build a unified architecture.”