Hi! I am very new to this forum and Universal Robots as a whole. What are the advantages of using UR script to program the robot?
You have access to different commands that can allow for more fine control of the robot. The Script manual is here: https://s3-eu-west-1.amazonaws.com/ur-support-site/115824/scriptManual_SW5.11.pdf
To add to what Eric said:
Everything you program in Polyscope is converted to script language - the Polyscope nodes just eliminate some of the work and possible errors for the actions they cover.
Every time you save a Polyscope program, it is saved as .urp file, .script file, and .txt file. By default, you only see the .urp files in the file manager, but the others are there.
The .txt file isn’t actually used by anything - it shows basically what the Polyscope program looks like in a text file form.
The .script file I believe is a human-readable version of the .urp file, which pulls in all the program steps, URCaps, functions, etc. that comprise the complete program.
You can pull these files out using a usb stick or using a file transfer program and pull the .txt or .script files into a text editor to view. This can be helpful to see just how the polyscope nodes work, or to steal script snippets for your own scripts.
As Eric alluded, there are lots of things which just can’t be done using Polyscope nodes, or just become easier within a script. In some cases it’s a tossup as to whether to use a script or a subprogram. Some people do essentially everything within scripts, just using Polyscope to call the script functions.
1 Like
A couple of examples:
I/O: Communicating with devices often requires scripts, unless the device manufacturer provides a URCap or it’s a simple digital or analog input/output.
For example, we communicate with a camera via Socket commands. These can be issued within single script nodes if they’re one-line commands, but in our case we also need to manipulate the data - we have to reorder the data bits, convert to useful numbers, then run through some logic to convert to usable coordinates for the robot. Much of this can’t be done easily or at all just using Polyscope nodes.
Similarly, when pulling in values from gages, we have to massage the data and make decisions based on the values. It’s generally easier to do this within scripts.
I’d be interested to hear from other users to see where they’ve chosen to use scripts vs. subprograms vs. straight Polyscope nodes/logic.
I tend to use pure Polyscope for the general skeleton, and usually the waypoints. I use scripts for any sort of data processing that needs to take place. Your example of manipulating camera data is a perfect example of this. Generally stuff I’d normally process on a PLC I do in scripts. I will also occasionally use scripts the same way I’d use a UDT or any other user-defined class in other languages. So I would write functions like “getCameraData()”, “convertCameraData()”, etc. This allows things to be easily modular and scales the complexity nicely.
I generally stay away from subprograms entirely. This is largely due to their inability to nest inside each other (subprograms can’t call subprograms) but script files don’t share this same limitation. And since they are called and defined pretty much exactly like subprograms anyway, I tend to just opt for these. (Example of this here: Jump Flag Program Node - #4 by eric.feldmann)
If it’s something that my company/customer is going to interact with frequently and I already have the script files written that works with it, it’s usually a small step from there to write a URCAP for it, which further simplifies the look. This lets me go from a script node calling the function “getCameraData()” to an actual Polyscope node called “Get Camera Data” and gives the user a simple interface for configuring the data request.
I definitely agree with trying to keep things modular and having the Polyscope part be mostly skeleton, if for no other reason than readability/debugging ease.
My most recent build was almost a copy of a system built by a former employee, so I modified the programs from the previous build. This includes a number of subprograms and threads. At least these can be collapsed, which helps some with readability.
If I was doing it over I probably would just use the previous programs as a guide, and start from scratch with a better overall structure. One of the subprograms, however, makes use of Direction . . . . Until nodes which look a bit more challenging to write as scripts. Similarly the Until Contact subnode seems to generate some pretty complex script code.
Similarly to eric.feldmann I use Polyscope for the basic functions and waypoints.
but use Scripts for any calculations.
Such as creating offset positions for depalletizing. calculating the position and quantity of parts based purely on the size of the parts I’m picking from a tray.
any socket communication (reading or writing data)
part counting
Task management (Reading lots of inputs and / or variables to make a programmatical decision)
I generally have a User_alarm script with all the popup messages all in one place and just call the User_alarm(#)
for the appropriate message I want to display. this keeps the PolyScope program tidier.
Hello everyone,
I am trying to incorporate sensor data into the real-time robot control via the URControl I/O. I am currently using Polyscope and adding UR Script commands like servoj() to the program. Unfortunately, I couldn`t find anything on the real-time communication between the Teach Pendant and URControl when executing the program. On the website, the primary client interface is mentioned, which operates at 10 Hz (Overview of client interfaces - 21744).
So my question is, when I compile a .urp code on the Polyscope GUI, is the generated .script file transmitted to the controller entirely or just line by line? So if it is line by line, I assume a communication at 10 Hz, since the controller waits for the next line from Polyscope. If the complete file is sent to the controller memory, then the control loop can be executed at 500 Hz, am I right?
Thank you in advance!