I think I’m missing something pretty basic here, but I’m pretty new to all this . . .
I’ve created a program on one machine (UR5e) which changes some values on LED displays through the modbus.
I’d like to copy that program to a couple other machines which use the same display setup but otherwise are different.
If I try to load the .urp files, it wants to pull in all the installation info, which I don’t want.
The .script file appears to also have all the installation info.
It won’t load the .txt file.
Seems like there’s probably a good writeup of how all this works somewhere, but I’ve scanned through the manual and done some searching, but haven’t come across it yet.
The only workaround I’ve come up with so far is to pull out the .script file, strip all the extra stuff, then pull it back in - might need to add a def and end statement to just make it a function call.
Can’t try this right away, as I have to get through some of our network security protocols to move stuff back & forth from my PC to the robot.
It sounds like you might be more after a script file as opposed to a URP file. If you have chunks of code that you’d like to run on multiple machines, you might benefit from structuring it almost like a Java class. Take, for example, this script I wrote for flashing outputs:
Now, I can use my own custom functions startDOFlash(outputNumber, rate) anywhere in Polyscope, almost like they were built-in commands. All I need to port this to any other robot is to throw the Flasher.script file into the before start portion (or anywhere at the top really) and that program will have access to these functions.
Does something like this help you accomplish what you’re looking for?
I think that’s basically what I’ll be doing.
My gripes are:
Since I originally generated the code from the pendant, it appears that I have to copy the .script version of the program from the robot, pull it up on my PC, then strip most of that file away to leave just the program. Then I have to feed it back into the robot as a subprogram. Our network administration makes us go through a lot of hoops to be able to copy files onto a USB stick, so if I could go directly from one robot to another it would be better.
I was hoping to find some general info which describes the way UR uses each of the file types, and how they interrelate. It appears that the .script file may just be a human-readable version of the .urp file, but I don’t know if that’s correct.
I’m accustomed to CNC programs, where the basic program is independent of machine-specific offsets, etc. and is fully portable between machines.
I’m hoping that most of this falls into place in my mind as I gain more experience. I have the advantage that we have several working robots with similar applications, but the guy who did most of the initial setup & programming is gone, so we’re trying to get up to speed.
The above is a nice workaround for what looks like you are trying to accomplish. To provide some further context-
What happens when you copy and paste a .urp file, is the installation file is tied with it. Any .urp file contains a reference to the installation file-which it was created with-that’s just how the file is structured.
However-if you are trying to just have the same .urp file for multiple robots with different installations-you would be to have a unique installation file per robot.
This way-all the robots projects are the same, but the installation files have their own DNA per robot.
I have tested this out and you will get a warning stating ‘installation file could not be found. would you like to use the currently loaded installation file?’ and you choose yes on this option.
This way-you can exclusively choose the .urp file, and move it onto different robots to keep their original installation file. (move it either via USB or via FTP i.e. FileZilla)
When I tried pulling the .urp file into another machine last week, I remember seeing something come up which made me concerned that I’d be changing some important configuration items in the installation, so I chickened out and restarted without saving.
I’ll look at it again tomorrow, on a system we haven’t really configured yet, to see how that goes.
