Universal Robots Forum

Popup on variable change

Is there a way to throw a popup when a specific variable is changed?

For example the program starts with finishedPart = False. When it changes I’d like to throw a popup so I can see what and where it’s changing.

The initial program that we got with our UR10e uses Gripper 1 to pick up the first raw part and place it in the vise. When machining is done on that first part the program picks up the next and all subsequent raw parts with Gripper 2.

The problem with this is I often need to use a certain shape of gripper finger for picking up raw parts and putting them in the vise but I need a different shape to pick up finished parts and put them back on the pallet.

So I want to always pick up raw parts with Gripper 1 and always place finished parts with Gripper 2.

TYIA.

Yes. You will want to use the Thread command in Polyscope.

Here’s something I threw together real quick for testing. You should get the popup any time you toggle digital_out[0]. You can replace that with whatever variable whose state you are trying to track. You may get an initial erroneous popup as the value is being initialized. I didn’t put much time into making it perfect.

2 Likes

Awesome, thanks. I will check it out when the next cycle is done.

Also you may want to note that a popup in a thread will not pause the main program from continuing running.
It will only block the thread it is called in.

1 Like

Oh. Shoot.

That explains why my simulator kept flashing when I ran it. :rofl:

Are the points where the grippers need to be changed constant on where they are at in the program?
If so, you could just put a popup at these locations where they need to be changed to inform the user of the change.

Either that or have a variable based on the current gripper and when performing the next section check what the current gripper is from this variable and if it is the correct gripper continue, otherwise throw a popup requesting the user to change the gripper. Once they click continue, set this variable to the new gripper value.

1 Like

They are constant in the program, but there are literally scores of them. The ones causing problems are in the “grey” node groups where you cannot use the single step function. These non-single-step-able nodes are in palletizing routines, there are around 125 nodes in this group that I cannot single step through so I’ve added some popups to debug with.

The tech that installed this robot did a lot of that already. I think that’s what’s making it so hard to navigate the program.

I did manage to get it going yesterday by adding my own variable and logic. Not the most efficient program but as long as it’s running I’m fairly happy.