Modbus TCP is one of our supported communication protocols and is really appreciated by our customers from the academic world because it is easy to interface with a standard PC. However, even though Modbus TCP is common in the broad field of automation, it is quite rare to see a robot controller using this protocol. Probably due to historical reasons, robot controllers are more often equipped with protocols such as Ethernet/IP, DeviceNet and EtherCAT.

In some cases, for example when the device will be used with different masters, it may be interesting to have a communication protocol which is compatible with a standard PC and robot controller. At a first glance, Modbus TCP often seems to be a good option because many robot controllers are equipped with ethernet interfaces. However, caution is necessary as three scenarios are possible. Lets take a look at them.

Scenario 1: The Controller has an Ethernet Interface which Cannot be Used to Control a Slave

This is unfortunately the most common scenario. Robot controllers often have the possibility to be connected to a network such that it can be programmed offline and the program is later uploaded to the robot. The interface can also be used to launch specific programs depending on the required tasks. In that case, the ethernet interface is used to control the robot as a slave and cannot be used to control another slave device using the Modbus TCP protocol. One example is the ABB IRC5, which can be connected to a LAN network but cannot use its interface to control a slave device from a program running on the controller. However, it uses standard protocols such as Ethernet/IP and DeviceNet which are very common (and compatible with our Grippers!).

Scenario 2: The Controller can Control Slaves with an Ethernet Interface but Modbus TCP is not Built-In

This is also common in the realm of industrial robots. One application of such an interface is to collect data from a camera, analyze it using a program running on the controller and then move the robot according to the results of the analysis. In this case, it is possible to develop a Modbus TCP driver to send commands to the slave device from the main robot program. However, this requires a lot of work and it is probably simpler to use another communication protocol if it is available. One example of this is the DX100 controller for Motoman robots. Even though it has an ethernet interface which could be used to control a slave device using the Modbus TCP protocol, it is a lot simpler to use another protocol supported by the controller such as Ethernet/IP or DeviceNet as these do not involve a lot of programming.

Scenario 3: The Controller is Modbus TCP Compatible

This scenario is not common for robot controllers. However, many Programmable Logic Computers (PLCs) such as this one from Advantech support Modbus TCP. In which case, controlling a device using this protocol is straightforward. In the case of an industrial robot with a gripper as its end-effector, it could be possible to use a PLC to control both the robot and the gripper but as you may guess, this is often not the ideal way of controlling a robot cell.

As a final conclusion, lets just say that Modbus TCP is a good protocol when custom-built robots and controllers are involved as it is open, simple and low cost due to the use of standard PC hardware. However, when industrial robot controllers are used, it is generally much simpler to use standard communication protocols such as Ethernet/IP, DeviceNet and EtherCAT.

If you want to know more, get the free Ebook on End Effector gripping strategies !