Communication protocols pave the way for robotic rule

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.

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 is senior staff software engineer at DWFritz Automation.

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 is CEO at Precise Automation.

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.

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 is executive vice president at TM Robotics.

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

ALSO READ: How to get started with robotics

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].