Introduction to Universal-Robots Script Programming
There are mainly two different approaches or ways to program a Universal-Robot – either with the very innovation Polyscope GUI interface using the touch screen teach pendant – or using the UR script language – or a combination of both of these two approaches.
Script programming on the UR can be performed by sending raw script commands from an external device to the robot – even without any program made in Polyscope on the robot.
Script programming on the UR can also be performed by adding script commands to a Polyscope program running on the UR robot itself.
Script programming on the UR can also be performed as a combination of having a server program running on a external device – and a client program running locally on the UR robot which is more elegant and it is possible to create better handshake and it is also possible to make “Functions”.
There are 3 ports 30001, 30002 and 30003 on the UR that can be used to send raw script from an external device. When creating a Client-Server scenario then it is better to use another port number that are not used on the system for example port 12345 or port 30000 etc.
UR script commands can be send from a host computer or PC via an Ethernet TCP socket connection directly to the UR robot for motion and action control without using the teaching pendant. For example if the robot is part of a big complex installation where all equipment are controlled from the host computer or PC.
But before jumping into the remote script programming there is also an alternative script programming method provide in the GUI via the teaching pendant as well which is also very useful. With this method it is possible to Import Script statements or whole Script files (for example as “Functions”) into the robot program created by the teaching pendant – so this method is something in between using only the teaching pendants program objects and the fully remote Script programming.
Notice:
There are a few things that is important to take note of when sending raw script commands from a external device. First of all it is important to pay attention to safety and make a risk assesment.
In the articles on the Forum Python® 2.7 is used as the scripting language for making these program for testing the script programming with the robot.
If sending raw script commands to port 30001, 30002, 30003 a Polyscope program will stop – so in this method it is either only raw script commands to port 30001, 30002 and 30003 – or only a Polyscope program that will work properly. So if a combination of script commands and Polyscope program is desired then a Client-Server scenario can be considered. Example of Client-Server scenario
It is also important to notice that when sending raw script commands via port 30001, 30002, 30003 there might be no handshake and therefore the programmer needs to control the communication flow and especially the timing of the communication flow. It is more elegant to make a Client-Server scenario where it is better possible to make handshake.
Also notice that when sending raw script commands to port 30001, 30002 and 30002 without a client program on the robot side – then these raw script commands is like a one way traffic – which means that it is possible to “set” things on the robot – for example to set outputs with the command “set digital out(n, b)”- or to send a move command like “movel(pose, a=1.2, v=0.25, t=0, r=0) ” – and the robot will set the output and also move the robot. But when sending raw script commands for reading or request for of status (for example the status of an input etc.) via port 30001, 30002 and 30003 then this is not possible to get a immediate response on a such request. For example if a raw command like “get_digital_out()” is send to port 30001, 30002 and 30003 then there is no reply for the status of the digital port requested.
Therefore some script commands like request for status is to be used inside a Polyscope program. There might be some feedback returned back when listening to port 30001, 30002 and 30003, but this is Matlab data – as decribed at this link. More informations about return data on port 30001, 30002 and 30003.
To “set” for example outputs or make moves with raw script commands then there are some examples at these links. Set output and move with raw script commands.
To get valid data back from the robot then either a Client-Server scenario can be created like shown at this link Client-Server example – or reading of MODBUS registers as explained at this link. Reading of data from MODBUS registers.
Timing:
For example when sending raw script commands via port 30001, 30002, 30003 then the commands are executed immediately – and it is very important to notice that if such command is not finish (maybe because the robot need to take time to move from one position to another) before the next command are send – this can result in that the first command is terminated (i.e. not finish) and will be overwritten by the next command. This is most obvious in commands where the robot need time to execute e.g. “to move” – or for example “to wait”.
If a command like sleep(5.0) (Python command for wait 5 seconds) is send as a raw script command over port 30001 or 30002 or 30003 – and then another command is send immediately afterwards – then this will not result in a 5 second wait on the robot because the second command will overwrite the first (sleep) command. Therefore when such raw command are send from an external device then the wait has to be performed on the external device before the next command are send to the robot. This means that when the programmer when using script programming from an external device – the programmer need to take control and to program the timing of the program and communication flow.
Some example of a wait on the external device side can be found at this link Example of sending Script from host to robot via TCP socket connection
And also in the case of sending “Functions” from an external device an example is shown at this link Example of Functions
When sending raw commands to the ports 30001-30002 and 30003 without a counterpart program made inside the Polyscope enviorment – then there are no handshake and therefore the timing needs to be controlled by the programmer.
Variables and loops and If-Else etc.:
Variables will not work when sending raw script commands because variables (and other programming technique like loop – If-Else etc) needs to be controlled either by the external host program (e.g. a Python program on the external device) – or within a Polyscope program. Such variable cannot be left in between a host program and a Polyscope program – there is no controller in between.
To send variables – make loops – use If-Else by using raw script commands – then such variables-loops-If-Else has to be controlled and designed in the external host device where the program is running. And to get informations back from the robot then the client-server method can be considered.
UR Script: Raw script commands example.
Example of sending Script from host to robot via TCP socket connection
UR Script: Client-Server example.
Example of a Script Client Server scenario
UR Script: Functions example.
Example of a combination of using Script script commands on the teach pendant and using functions
It is also important to mention the separate document and manual for Universal-Robot script programming called “scriptmanual_enx.x” where the commands with their parameters are explained.
Pros and Cons of programming technique.
Polyscope programming.
Because Polyscope programming takes place inside a programming enviorment then timing and flow control is easier to handle because it is often taken care of by the Polyscope enviorment.
Script programming.
One advantage by using remote script commands is that the program can be further developed, edited and tidy up while the robot is running production. This is also possible to do with GUI programs by using the simulator. Then when there is a break in the production the new modified program can be activated and control the robot right away (provided the programmer did not make any programming errors in the new version).
The differences in using the teaching pendant and the remote scripting method is that when editing with the teaching pendant the program execution has to be stopped while editing and thereby interrupt the actual production whereas editing in the host application can be done aside from the running version and thereby not disturb the production.
Another advantage is that the host application programmer can make new functions and features and basically create a complete new user interface and functionalities to the robot and handling of the data and interfacing with even other computer systems to the programmer’s creativity abilities.
The Universal-Robot offers such possibilities to make remote script programming with its build in script interpreter. The choice of programming environment on the host computer is up to the programmer and typically programming languages such as for example C++, Java, Visual Basic, or Python or similar, but even Notepads can be used as an editor.
There is also port 30004 for real time interface and some more informations about the real time interface can be found at this link
Real time interface port 30004
Disclaimer: While the Zacobria Pte. Ltd. believes that information and guidance provided is correct, parties must rely upon their skill and judgement when making use of them. Zacobria Pte. Ltd. assumes no liability for loss or damage caused by error or omission, whether such an error or omission is the result of negligence or any other cause. Where reference is made to legislation it is not to be considered as legal advice. Any and all such liability is disclaimed.
If you need specific advice (for example, medical, legal, financial or risk management), please seek a professional who is licensed or knowledgeable in that area.
Author:
By Zacobria Lars Skovsgaard
Accredited 2015-2018 Universal Robots support Centre and Forum.