We have several of these robots in duplicated systems. We have 1 code base but because of mechanical build up tolerances each robot has slightly different teach points. Right now it saves the point in the program so if we make a code change we have to change the code manually on all robots which is a huge pain. If we were to deploy the code to all the robots using the single program it overwrites the teach points and everything is off.
Is there a way to separate the teach points from the program so we can update code and not overwrite the points?
would it be possible for you to use Subprograms, which will then be changed to only affect a part of the whole program?
Another way could be to extract maybe the logic into a script-file, which then will be changed, but the program itself, with its waypoints stays the same.
Could an alternative approach be to save the key waypoints as feature points in the installation, and then when you make a code change only copy the new .urp and leave the .installation file unchanged?
I have been trying several things to handle external teach points. Sub programs did not work. Scripts did not work. UrCaps can’t do it. I did however get something that looks like it works. (ajp’s idea!)
The idea is that the teach locations are saved in the installation file which is separate from the program. When we make code changes we only copy over the .urp file and not the installation file.
In the installation tab under Features you can create Point features. This is where you define all the teach points and set/modify the points. Then in the program you use variable points which use these features.
The only thing this will not work for is the pallet corners as those can not be set to variables. If UR could make it so those could be variable positions we would be golden!
You can access the pose and the joint-vector of a waypoint by adding the suffix “_p” and “_q” to the waypoint-name. Hence you can change the pose of the “pallet_corner_1” by scripting something like:
“pallet_corner_1_p = my_feature_corner_1”
“pallet_corner_1_q = get_numerical_inverse(my_feature_corner_1)” .
In order to make the code have an effect you must stop and restart the program because the script-generator will have to run in order to generate your new palletizer. To make this easy you could raise a flag if:
“pallet_corner_1_p != my_feature_corner_1”
and then halt your program after you have made the change. I have tried this with an UR5 e-series.