Communication interfaces

Technical Questions Robot Communication
1

(This post is a Wiki, experienced developers can modify the content)

It is possible to connect to the robot using the Ethernet port in the bottom of the controller cabinet.
There is one port available. Consider using a switch, it you need to use this port, to increase flexibility and enable connecting additional devices.

TCP/IP 100 Mbit: IEEE 802.3u, 100BASE-TX (1)

The robot can be set up to have either a static IP or use DHCP in PolyScope.
Internally, it is possible to connect to the robot on localhost: IP 127.0.0.1

There are a number of servers and interfaces running always in the robot:

  1. Primary client interface
    Port: 30001
    Constantly transmits a data stream about the robot state + additional messages.
    Can receive URScript codes and URScript programs.
    Running at 10 Hz.
    See more at the UR Support Site
  2. Secondary client interface
    Port: 30002
    Constantly transmits a data stream about the robot state.
    Can receive URScript codes and URScript programs.
    Running at 10 Hz.
    See more at the UR Support Site
  3. Real-time client interface
    Port: 30003
    Constantly transmits a data stream about the robot state.
    Can receive URScript codes and URScript programs.
    Running at 125 Hz.
    See more at the UR Support Site
  4. Real time data exchange (RTDE)
    Port: 30004
    Transmitting selected robot state data.
    Can receive commands for outputs, external force/torque sensors and more.
    Running at 125 Hz.
    See more at the UR Support Site
  5. Dashboard server
    Port: 29999
    Can receive commands to load, start and stop installed programs, and answer to robot state requests.
    See more at the UR Support Site
  6. FTP server
    Port: 22
    Warning: The file system is not write-protected. Be sure which files you are working with, as damage may be caused to the UR software.
    Host: IP address of robot
    User: root
    Password: easybot
  7. Modbus server
    Port: 502
    Contains robot state data and general purpose registers.
    See more at the UR Support Site

NOTE:
It is generally recommended to use RTDE and fieldbus protocols (Modbus Client, Ethernet IP or Profinet) rather than the Primary, Secondary, Realtime and Dashboard server interfeces.
The recommended interfaces are actual API, and provide elements of versioning, backwards compatibility and protocol negotiation. The other interfaces are semi-API, and does not provide things such as backwards compatibility and may change or be deprecated without notice.

Using the client interfaces

The primary, secondary or real-time client interfaces can receive URScript commands for execution.

Example 1
Sending a single URScript command:

set_digital_out(0, True)

This command will set digital output 0 to high.

Example 2
Sending a URScript program:

def myprogram():
	movel(p[0.2,0.2,0.0,0,3.14,0],a=1.2,v=0.25)
	movel(p[0.4,0.2,0.0,0,3.14,0],a=1.2,v=0.25)
end

This URScript program will be executed upon receiving it by the controller.
Thus the robot will first do a linear move to the position p[0.2,0.2,0.0,0,3.14,0], and then to the position p[0.4,0.2,0.0,0,3.14,0], where after the program has ended and stops.

URScript codes are explained in the URScript Manual, which is included in the URCaps SDK.

Both the script code in example 1 and 2 will halt any already running program in the controller, thus cannot be done simultaneously.
Alternatively a ā€œSecondary Programā€ can be sent.
The secondary program is not allowed to use any physical time, e.g. movement of the robot, but does not affect exiting program execution. Read more.

Example 3
Sending a secondary program:

sec mysecondaryprogram():
	set_digital_out(0, True)
end

This program will turn on digital output 0 without halting the primary running program. It may not use any physical time (no move or wait commands).

Ethernet raw

It is possible to use other ports than mentioned above for Ethernet raw communication.
From URScript ir is possible to open a socket connection using:

socket_open(ā€œIPā€, port, ā€œsocket_nameā€)

Where the IP address and socket name must be a string, and the port an integer.
It is possible to transmit and receive string, floats and integers using socket connections from URScript language.

These options are further explained in the URScript manual.
It is also possible to open a socket connection between a daemon process, e.g. as listener, and the program, e.g. as the client.

Optional communication interfaces

The robot does also support following industrial fieldbus protocols:

  1. Ethernet/IP (from software version 3.2)
  2. PROFINET (from software version 3.3)

Also check out this article: Overview of client interfaces - 21744

2 Likes
3

hi

The robot arm is powered off once I am trying to send UR5 a second program as below code during the robot is running with primary program.
sec mysecondaryprogram():
set_digital_out(0, True)
sleep(0.5)
set_digital_out(0, False)
end

The Polyscope is 3.3.2.266.
Is this a bug already knowen or I made some mistake?

5

Hi James,

The page about secondary programs on the support site states:

"A secondary program may not take any physical time to execute"

The sleep command in the above example uses physical time, and is therefore not permitted.

A single set command as shown on the support site example works fine:

sec prog():
  set_standard_digital_out(1, True)
end

@jbm Can I edit the above wiki? Donā€™t seem to be able to at the moment.

6

@ajp
Trust Level 2 is required to edit Wiki posts.
You have just magically obtained TL2.

Gaining trust level comes from reading posts, and creating new topics and replies.

7

Iā€™ve noticed that when testing comms in a PolyScope program, the program needs to run with the real robot selected. When Iā€™ve tried the with the ā€œSimulationā€ (virtual arm), commands such as socket_open() do not time out (or do anything in any way for that matter).

Please note Iā€™m talking about the simulation in the real control box, on the teach pendant, not URSim/desktop simulation. If you try socket commands in the latter, they work fine in both ā€œreal robotā€ and simulated robot modes.
But Iā€™ve tried with physical UR5 and UR10 robots and the commands didnā€™t work with the simulated setting.

This also applies to XMLRPC servers running on the control box, such as the one shown on the mydaemon example on the URCap tutorial.

It would be nice so be able to setup and test comms just with the control box, without needing the physical robot connected (just a humble feature request).

8

@nicolas
Thanks for your testing notes and feedback.
I have not been aware of this fact.

9

I tried to send program to robot using ā€œ\nā€ between two lines, such as ā€œdef abc():\nset_standard_digital_out(1,True)\nend\nā€, why donā€™t hava any effect? while it is ok with single command with ā€œ\nā€. Could you help to point out?Thanks.

10

It depends much on which application/software you are using to transmit the code.
E.g. if it interprets the \n as a newline char or as two string type chars "\" and "n".
Using SocketTest will typically interpret it as string chars, while e.g. transmitting it from a LabVIEW socket connection could interpret as a newline char.

You should also try to add a space between \n and the next chars.
def abc():\n set_standard_digital_out(1,True)\n end\n

11

I believe the primary and secondary interfaces execute commands immediately when received. So if you send two commands together, the second command overwrites the first. In contrast, a script file will execute commands sequentially, it will only execute the second command after the first is finished.

12

Thanks, Jacob. I finally found the error is indentation. Strictly complying with the indentation rules is needed.

13

Hi, it is ok to send some commands together once you include them in one function block, like def yourfunction():\n you code\nend\n

1 Like
14

Thanks for sharing that. Itā€™s weird that the function is also executed on definition, but it definitely helps.

15

if you look at the script file that PolyScope generates, you can see the same structure.

1 Like
16

It seems that secondary programs cannot modify variables used by the primary program, like:

sec mySec(): \n global someVariable = ā€œsome_valueā€ \nendā€™

Is this correct?

EDIT: I believe Flags can be used to get around this in the case of boolean variables.

2 Likes
17

Hi, is it possible to connect devices to the robotā€™s USB port and read from them using custom Python code? Thanks,
Nikolaus

18

Yes, it is. Nikolaus.

20

Hello SonglinCai, Can you show me the example to use it in socket test, Iā€™ve been doing many tries but canā€™t show a simple popup using def exam(): structure

21

Hi David,

Thatā€™s because in SocketTest, you canā€™t input the ā€˜\nā€™ as it is. If you want to use def structure, you need to turn to other programming method, like python, java or C#. Or you can find another tool, which supports raw data input.

22

Thank you for your quick response, Actually already did it with python, but I really wanted to know how to do it with SocketTest, but itā€™s ok then, Thanks a lot

23

Note that this library implements all these protocols in .NET (C# / VB), Python, MATLAB and LabVIEW