Communication protocols pave the way for robotic rule

Robot roundtable

This article is part of a series on how to prepare for the reign of robots through:

Communication protocols are having a profound impact on robot integration in industrial machinery. Robots are taking over the world. Some countries are so concerned with rapid robot expansion that there’s been discussion of a robot employment tax to counter the displacement of workers caused by robot implementations. Chinese appliance maker, Midea, riding the momentum of its $4 billion acquisition of Kuka, intends to fend off Japanese competitors and dominate the world’s largest robot market.

There’s a lot at stake. With the rise and convergence of the Industrial Internet of Things and collaborative robot applications, the possibilities are endless. And a sure sign of the times was Schunk’s collaborative robot gripper, with embedded intelligence and two cameras, winning the Hermes Award at Hannover Messe 2017.

The sky’s the limit on robotic industrial applications. We asked a variety of industry experts some specific questions about where robots are headed and how they plan to get there.

As robotic control, sensing and actuation converge with communications and the Industrial Internet of Things, protocols become important considerations. From EtherNet/IP, ControlNet and DeviceNet to Modbus, Profibus, EtherCAT and CC-Link, different protocols can create technical troubles and increase integration costs. How does a machine builder include robotics flexibly, sustainably and affordably?

Bhaskar Ramakrishnan, DWFritz Automation: DWFritz tests most of the protocols upfront, so that we are not surprised when it comes to execution. We spend a good portion of our income understanding new technologies and building APIs to make them compatible with system software. We use object-oriented programs that make system integration and debug easier. Having a repository of these tools enables us to quickly adapt to different customer requirements.

Bhaskar Ramakrishnan is technical sales engineer at DWFritz Automation.

Henrik Jerregard, ABB: The observation that industrial networks exist in many different standards and protocol is indeed a true observation. Generally, the trend is that the industry is moving toward Ethernet-based protocols, but it is slow-moving progress. Each fieldbus has its strengths and weaknesses, but generally they are all very capable. The choice of fieldbus often comes down to regional and company preferences.

For robot manufacturers, this is a challenge since compatibility to many different fieldbuses is resource-and-development-heavy. For machine builders, it is somewhat simpler since most major robot manufacturer do support the most common fieldbuses.

One global standard would for sure be the best, but unfortunately that is very unlikely. With respect to the Industrial Internet of Things (IIoT), the OPC-UA protocol is a promising protocol that, in the long term, might take the industry closer to one standard.

Henrik Jerregard is global product manager, robot controllers at ABB.

Daniel Moore, Universal Robots: In general, there’s no shame in sticking to what you know. Many robotic systems include various fieldbus protocols natively. Shop around for the robotic system with the best combination of programmability and familiar interfacing, and only plunge into a new interface after doing a thorough cost/benefit analysis and you’re positive you can retain your talent after you pay for their training.

Daniel Moore is tech support manager at Universal Robots.

Mike Van Hoomissen, DWFritz Automation: We typically choose devices and protocols that will have a long life, are industrially proven, perform at high speed and with a high degree of configurability.

Mike Van Hoomissen is senior staff software engineer at DWFritz Automation.

Patrick Laughter, Denso Products & Services Americas: Product familiarity or customer requirements are the decision-making factor when it comes to component selection. If a machine builder is more familiar or the staff is more familiar with a particular controls platform, they will go with that platform. Less learning curve results in shorter build/design time. But sometimes the platform meets the requirements of the system, such as high speed I/O.

Patrick Laughter is engineering manager, robotics, Denso Products & Services Americas.

Maximiliano Falcone, Kawasaki Robotics USA: Protocols become important when specific needs are identified for a given project. As with any industrial solutions, line builders need to look to the future needs of the machine or cell being built. Certain questions need to be asked to properly assess which protocol is needed. Is there a possibility for an increase in production? Will there be future products introduced to the line? Is there existing equipment on the line that already uses a certain protocol that the new equipment will need to communicate with? These are all good questions to ask up front. But also there is a need to look to the past. What protocol is the customer comfortable with? Has a similar operation been done already where some non-recurring engineering (NRE) can be taken advantage of? And then lastly geographic regions become a factor, as well. All these points affect the protocol chosen as part of the solution due to their flexibility, ease of use and local acceptance.

Line builders and end users need to be able to design a certain amount of flexibility into a solution to account for future expansions. In the past if a system was deployed with the exact amount of I/O needed, then future changes meant big dollars running wires for new functionality. Nowadays with fieldbuses these additions are much less invasive; however, if this flexibility is not designed in at the onset, future expansions could still be costly by requiring additional hardware.

So, the question becomes how much future expansion does one accommodate for in the initial design? As a rule of thumb, we have always designed to 20% additional capacity, and, if a customer knows they have future goals for greater expansion, we may take that up some percentage based on the case.

Here in the United States, 90% of what we have done on the general-industries side of the business has been Ethernet-based protocols with some CC-Link, DeviceNet and discrete I/O filling in the majority of the remaining 10%. So, for an Ethernet-based protocol, the big "gotcha" that has bitten us in the past has been ports. It seems like, on 10% of the jobs, we are adding a switch somewhere for some latent need. The name of the game is now real estate within our panel. So, 20% is not specific to I/O points but also, ports, physical panel space, heat calculations and floor space.

No one has ever told us to use as much floor space as we want for our panels. In fact, the opposite has been the case on most occasions. However when it’s explained clearly that a little extra now can save you time and money later, opting for a larger panel that can have an Ethernet switch added to it or some distributable I/O is critical for success.

Maximiliano Falcone is senior manager, general industries engineering at Kawasaki Robotics USA.

Brian Carlisle, Precise Automation: The most widely accepted communication protocol is Ethernet TCP/IP. Derivatives of this, such as EtherNet/IP, are proprietary vendor implementations, typically not supported by other vendors. Proprietary fieldbus protocols such as Modbus, DeviceNet, CC-Link and EtherCAT have some multi-vendor support for automation products, but this tends to be limited. For example, most camera vendors offer Ethernet and USB-2 or USB-3 cameras, but not EtherCAT or Modbus. As the Internet of Things (IoT) expands, the likely protocols will be Ethernet and USB. Vendors will need to support these standard protocols in addition to any proprietary networks they wish to promote.

Brian Carlisle is CEO at Precise Automation.

Erick Rudaitis, Parker Hannifin: There are many options now for robots; most end-of-arm network considerations are determined by the network the robot is connected to. If the robot is connected to EtherNet/IP, then the end-of-arm tooling most likely will also be EtherNet/IP. With the increase in smarter devices giving more prognostic information, there now comes a need to get that non-process data to an outside-the-work-cell environment to be analyzed. From our viewpoint at Parker Hannifin, we see IO-Link as a possible common standardized I/O technology that would provide flexibility, prognostics and a lower installation cost based on the architecture. Flexible manufacturing is becoming more prevalent, requested by manufacturers so they can do more with less. The components chosen must likewise be flexible and able to change on the fly to accommodate this methodology. We are seeing that many currently available smart IO-Link products, such as programmable sensors and actuators, can offer true savings and make a smarter prognostic-based system.

Erick Rudaitis is market development engineer—factory automation at Parker Hannifin.

Matthew Bush, Hirebotics: Communication protocols are an important part of any machine build and determining which to include for not only the current system architecture but to afford any upgrade or expansion in the future is critical. As we deal with Universal Robots and do not tend to use a separate PLC but rather use the robot for all cell control, we stick with Modbus TCP for expansion I/O. We then use TCP/IP for connection to the cloud infrastructure that we have built for monitoring the robots in the field. We also use this cloud connector for implementing other services into the cell such as cameras or customers’ equipment. We do this as it gives more control to us to alter how we are using the equipment without the need to update the robot operation or program. Utilizing standard architecture such as TCP/IP socket communication or XML remote procedure call (RPC) gives us a large library of well-tested and stable frameworks to choose from, as well as the ability to quickly expand the functionality of the robots in the field. We are then able to use this on previously installed robots and quickly provide enhanced functionality or monitoring in the field.

Matthew Bush is COO and co-founder at Hirebotics.

Lee van Every, Cenit North America: One way to affordably include robots in a manufacturing environment is to use a simulation-based 3D-software solution to map out what is needed. There are engineering firms or engineering software available that can help a company map out the floor space. This gives the ability to decide on how many robots are truly needed to achieve the goals of production. Utilizing software to configure an environment can help to cut down costs since you will see the simulation of it before the actual equipment is ordered.

Software also offers the ability to be flexible, especially if it has drag-and-drop functions for introducing equipment virtually. If the software can also generate robot programs that are valid, that will also be a time saver. This would mean no shop-floor programming, as the automation cell is typically waiting for parts to come in before programming begins. Sometimes the parts that come in are not correct or the fixturing is not correct. The simulation tool at least gives a headstart on the initial programs, and alterations can be made quite quickly afterward.

With simulation and collision detection, you are also creating a safer environment for the automated cells, which leads to a longer lifespan of equipment. Things tend to last longer when they are not accidentally crashing into each other. Simulation definitely helps to prevent those types of shop-floor issues.

Lee van Every is senior account manager at Cenit North America.

Gary Eliasson, On Robot: The RG2 gripper from On Robot does not need any communication protocol. It is designed to work with the Universal Robots family of products. Once mounted to the arm, the gripper simply plugs into the I/O port at the end of the arm. We use the internal architecture of the robot to communicate how far to open and close and to adjust the gripping force, as well. The gripper also provides feedback in the form of measured width of the product when it is gripped and if the product is dropped.

Gary Eliasson is general manager, North America at On Robot.

Ryan Guthrie, TM Robotics: It’s important for machine builders to communicate with manufacturers and suppliers of robots to ensure they are unlocking the full potential of the robot equipment. The machine builder needs to have a clear understanding of how the overall system is going to be controlled, and the manufacturers needs to be certain they are educating the right people on both the full functionality and the limitations of their equipment.

Ryan Guthrie is executive vice president at TM Robotics.

Jim Lawton, Rethink Robotics: Our focus since the inception of the company has been identifying sources of friction associated with deploying robots in order to make robotics as flexible and affordable as possible. Communication protocols and the ability of robots to interact with other devices and software can be a significant source of friction. We have designed our Intera 5 platform to be able to quickly and seamlessly interface with the entire workcell and the software that manages the shop floor.

Jim Lawton is chief product and marketing officer at Rethink Robotics.

ALSO READ: How to get started with robotics

About the author

Mike Bacidore is the editor in chief for Control Design magazine. He is an award-winning columnist, earning a Gold Regional Award and a Silver National Award from the American Society of Business Publication Editors. Email him at [email protected].