Hi, I have a requirement where a robot is working with various products but on any given day the combination of products may be different.
If I was doing this on a “traditional” industrial robot e.g. Fanuc, Yaskawa, ABB, I would have a program for each individual component. Then I would have a program for each combination that then calls the component program as required.
e.g.
running product A and product B
Main program would call program for A if line 1 is ready, call program B if line 2 is ready
running product B and product C
Main program would call program for B if line 1 is ready, call program C if line 2 is ready
running product A and product C
Main program would call program for A if line 1 is ready, call program C if line 2 is ready
The benefit to this approach is that if I need to make a change for product A I do that in one place only.
I cannot seem to find any means in URScript whereby a program in UR can call another program (especially this would need to be nested such that when program for A is complete, control returns to the calling program). This means that for every combination of product, of which there are many, there will be a unique variation of the code for each product, this would be a huge headache for production people to maintain.
Any solutions?
You mention URScript, but if you use the “Subprog” in regular Polyscope you can achieve what you’re looking for. You can still do it in URScript, but the full code of each job would have to be accessible to the main script (ie copy/pasted into one big script). To call a subprogram from URScript, you just type PROGRAM_NAME(). So if I wanted to call the subprogram “mySubProgram” in URScript, I would just type “mySubProgram()”
Yeah I was aware of that option, but 1 huge script is not going to be pleasant for anybody. I was hoping to be able to call the base level program files rather than sub-programs, thats possible in other robots but not UR for some reason?
Guess I’m not understanding what exactly you’re looking for then. Subprograms ARE just base level programs. You can program Job A, B and C independently, on their own. Then you can have a master job set to run “subprograms” A and B. Then another master Job to run A and C. You can do this for all combinations. There’s a checkbox on the subprogram that says “Keep SubProgram File Updated with this Program” at which point I believe you would only need to update the individual job on its own, once, and that would propagate the change to all master jobs that reference it. Either that, or you just have to reload the newly changed subprogram into the main one. I forget which way it goes.
Like Eric said, the only way to acheive this is using Subprograms. And like you said 1 huge script is not pretty.
This is exactly how my UR’s are setup, and if you decide to go that route heres a few tips i have learned.
Setup a MASTER job, traditional robots use a master/parent job that loops while waiting for something to do, from this master job is where your case statement will be with various SUBPROG calls.
I always add a BEFORE START sequence to my job to reset any/all IO used in the programs, and bring the robot back home safely. If you want more details on how to check if home, i can share that.
Next, setup a model specific job… I used the naming convention M1_{name], M2_{name} etc. this makes it simple to see what is going on and organizes the subprograms nicely.
Most importantly, you have to name your waypoints uniquely per job.
For example, I breakdown my names by {ModelNumber}_{OverallPath#}{Waypoint#onPath} i.e. M1_100, M1_102, M1_201,M1_202…
This naming structure makes it easy to find a position you need to touch up, and satisfies the unique name requirement of the master/parent job.
Once you have the subprograms linked to the master job, check the two boxes “Keep in Sync with job” and “hide subtree”, this keeps the master job fairly clean & readable.