How to prevent renaming variables when using Subprog?


How can I prevent Polyscope from asking me to rename variables when using “Subprog”?

Some context:
I made a program which I use for machine tending. It runs well, only I want to split the program into two programs. A part specific program and a generic program. From the generic program there will be 1 version and from the part specific program I can have as many as I want. This allows me to easily deploy a change in the generic program without going through all the part specific programs.

So far I am able to create this situation by using the function “Subprog” inside the part specific program. Only everytime I open the part specific program I get the question if I want to rename the variables that are used in generic program as they also exsist in the part specific program. This is not desired.

Do you have any suggestions for me?

Were you ever able to find a solution for this? I am having the same issue.

I’m struggling with the same thing. using subprograms makes a lot of items cleaner for people following behind me so you are only messing with the section of program you want to. but the renaming variables messes everything up, especially with palletizing

Every time I’ve dealt with this, I always just spam cancel when it yells at me about renaming them.

I did that but the palletizing still broke. When I first made the palletizing sub it worked great, changed the machine over and ran a different part, spammed the cancel button when loading the 1st program and then everything was broke.

For what it’s worth, I’ve seen several instances of Palletizing nodes not working properly in subprograms when they are opened. As in, the first time you program it, it works great. But if you turn off the robot, or open a different job, when you come back, it’s broke.

ok. That sucks. also really annoying that you cant pick the variable for palletizing, you have to create a local variable.

I would kill for some jump labels so I dont have so much duplicate code nested in if thens

This might help you there then, I dunno.

Thanks. Might still run into the palletizing in a subprogram issue.

Nested palletizing. And I need to present the part to the operator for a quality check. if it passes, run the rack of parts, if it fails the operator can rework and reinsert into system, needing a quality check on the next part.

Here is my pseudo code.

Not sure if the UR will handle two folders of the same palletizing in one program, using the same variable as each other… but Ill find out tomorrow unless someone has a better solution. If i had true jump labels I could jump into and back out of one copy of the palletizing logic.

I find, in general, that the palletizing template is less than ideal. It’s too simple where it needs to be a little more advanced (ie picking the palletizing variable) and too complex where it could be made simpler (lots of node insertions and makes a relatively cluttered tree).

There are other CAPs that refine this much better in my opinion. However, if you’re doing a relatively simple pattern, it’s actually not hard to make your own. All it’s doing is shifting a Feature around. We do this very simply in our Welding CAP and it looks like this:


Just type in your offsets and then any other logic you put inside it will just get shifted around appropriately. So if you’re working with just a regular ol’ square pallet, you may find more success just doing it yourself outside the Pallet template.