With the rising popularity of vision systems and other robot-aiding instruments, it is now common to see robots take on more and more intricate tasks. This creates situations where robots are handing off parts to each other and in doing this, they need to communicate robot to robot to maintain efficiency and fast production times. Universal Robots have an arsenal of communication protocols to satisfy almost all new and old networks, including: MODBUS, ProfiNet, EtherNet/IP, TCP/IP, and XMLRPC.
TCP/IP and Remote Control
One of the more popular communication methods used with Universal Robots is a simple TCP/IP socket connection via Ethernet. Why is TCP/IP popular? Many of the readily available Remote Control Servers that run on all UR’s, including a Primary, Secondary, Real-time, and Dashboard server, utilize the TCP/IP protocol. These servers accept various commands remotely from a client program running on an external device or another robot. In the case of a part handoff between two robots where the timing might vary depending on the previous task, the Dashboard Server can be used to start, pause, or stop the robot. For an example of the Dashboard Servers in action, watch these two UR3 cobots in action solving a Rubik’s Cube:
Each robot moves three sides of the cube, but some of these moves require the other robot to hold the cube differently for the robot actually rotating one of the sides. To accomplish this, the robot holding the cube will move to a different position and tell the robot moving the cube when it is ready. Then, the holding robot will pause its own program and wait for confirmation that the side has been moved from the moving robot.
The Dashboard server has much more functionality that just starting/stopping the robot. For more information on Dashboard Server commands and usage, see Article 15690 on Universal Robots support page.
Alternative Remote Control Servers
The Dashboard Server provides access to very high level functionality, such as loading programs, getting robot states, and turning it on and off. More specific functionality, such as moving the robot, is archived through the Primary (port 30001), Secondary (port 30002), or Real-Time (port 30003) Servers that also run on the robot. These servers listen for URScript commands such as:
- movej(pose) move the robot to the specified pose
- sleep(seconds) have the robot wait a number of seconds
- freedrive_mode() send the robot into free drive mode
These are sent as encoded strings to the robot which are executed immediately. This might be helpful when the handoff point between two robots varies from time to time; the robot with the part can tell another robot to go to a specific point based off where it is handing off the part, or to tell the robot to wait where it is for a defined amount of time. To learn more about URScript and its native functions, download the URScript Manual (SW3.5).This functionality enables UR robots to be operated remotely, hence the collective name for these servers: Remote Control Servers. If there is some specific functionality that isn’t natively supported by URScript, predefined functions can be written and included in the robot’s preamble, so that these commands can now be understood when sent over a Remote Server.

Testing the Dashboard server: For testing purposes a program for testing sockets can be used, like HyperTerminal, or similar. In this example the freeware program SocketTest is used
When XMLRPC comes in handy
Another communication method I want to talk about is XMLRPC, which stands for XML-formatted Remote Procedure Call. This is not necessarily used for robot-to-robot communication, but is extremely useful for performing functions during runtime that are impossible to support through URScript. An XMLRPC can call a program or predefined function written in another language during runtime. This is especially useful for routines that are not compatible with the URController and need to be executed separately. To read more about XMLRPC functionality, read Article 16326 on Universal Robots Support page.

At Task Force Tips in Indiana, USA, two UR5 robots work in tandem in a vision controlled machine tending application. All communication between vision systems and robots happen through MODBUS.
Get the ebook on MODBUS
The MODBUS protocol, an industry standard, is used frequently throughout the robot industry. Although MODBUS is often times used along with a MODBUS controller, the protocol can be used by itself for yet another robot-to-robot communication method. Axis New England, a UR distributor, has created a convenient ebook that lays out how MODBUS connections are setup, and what is needed to configure communication between two robots. The ebook also introduces example programs using MODBUS registers to send coordinate information between two robots, complete with a download link to the example program and a video of the program in action.
Comments