Polyscope 5.10.1.1.
I have custom payload settings. When I “set now” it sets it. If I change tabs and go back to installation it shows the default payload in the drop down and has the default payload settings in the text boxes.
The Set Now button is also active so I doubt it’s changing. It’s just not persistent when you switch windows.
I set the Payload in the below image.
Then I clicked the TCP window then back to the Payload window and got the below.
So now I have no idea what payload setting is active.
Is this an oversight (like the Active TCP in the Move tab not updating?) or is there some logic to this highly annoying behavior. 
Dropdown boxes like that have to have some sort of default item to display when they are added to the screen. My guess is they’ve chosen to default to whatever Payload you have flagged as “Default,” (the little green flag thing) not the one you have set as active. I don’t have 5.10+ on my simulator so I don’t have the dedicated Payload setting to verify. But if you set Payload_1 as default, does that show up first when you switch screens?
@eric.feldmann is right. If you press the dropdown it should display a checkmark next to the active payload. I am not sure I understand what you mean by the active TCP not updating in the move tab?
You do have a point in the fact that the way the user sets the active TCP and the way the user sets the active Payload is not consistent.
Yes, it always displays the default (whatever that is set as). This is highly annoying behavior and is causing a lot of back-and-forth while dealing with 4 different payloads in one program.
From another thread. Easy: Auto Update "Active TCP" Box in Move Screen / Robot
Also happens when using Eric’s bitchin Set Active TCP Cap he made for us. Change Active (Set) TCP in the Move or Installation -> TCP Configuration interface
Do you uhhh…want me to add Payloads to that cap? 
Hello,
Whichever payload has the black check mark next to it is the active payload. If you set the default as active, you’ll see both the black check mark and green flag. I certainly agree that this behavior is not intuitive.
If you want to confirm that you’ve set your payload programmatically, you can assign one of the below script functions to a variable.
I LOLed. 
I do but I want you to get paid by UR for fixing the obvious and simple things that should have never left BETA testing the way they currently function. Many AE’s neglect basic functionality due to lack of day to day use of the tools they work on.
UR should hire someone like me in the product development department. Especially if Doosan ever figures out how to make a user-friendly GUI. Once that happens it’s gonna be on like Donkey Kong. 
Not intuitive is a nice way to put it, lets go with that. 
That was my first consideration. Seems very clunky.
It would probably be easier to select the drop-down and scroll to find the black check mark. Luckily I don’t have too many payloads set but the number goes up every time I add a new part. This will become a problem soon and I’m probably going to get more irritated at UR for not addressing it as it gets worse. Like the system slow down when you have more than a few hundred stupid backup files in your folder with zero way to manage them. That is a PITA every single day for me.
I’m getting off topic. Sorry.
My main point I guess is the concept behind having things like the Payload display and the Active TCP display actually display, you know… the current Payload and/or TCP when they update.
It’s like having a fuel level gage in your car that doesn’t update the current fuel level until you put the car in Park. Yes, it works. But it’s redicuous to have to stop every time you want to check your fuel level.
OK so I added the Payloads to the CAP, but in doing so I actually noticed that the active payload DOES update in real time on the Installation screen.
You can ignore line 2, that was my own debugging. If you run this code, then open your Installation page, you should see the dropdown box actually toggling in real time. If your’s is NOT doing this, update Polyscope. My simulator is running 5.11.8 and it’s doing this.
I checked the TCP hoping for a similar result, but sadly the TCP still isn’t updating in real time.
Yes, the payload updates in real time when you change it AND you’re still on that tab AND in that node but it is not persistent.
Once you click another tab or a node or anything that moves away from the payload screen then go back, it’s back to default showing in the drop down box AND the text boxes with the Payload values even though the correct one is loaded. You just can’t see that it’s loaded unless you look for the check mark in the drop down.
Well I didn’t get paid by UR, but I did add payloads to the CAP. That was mostly copy/paste logic from the TCP side. And I went ahead and made them automatically update in real time without needing to close/open the toolbar. That was…a little more work than I expected.
Ironically, the only way it DOESN’T automatically update the toolbar is if you use that “Test” button on the Set nodes to set the TCP as active. But since that’s a pretty dumb way of setting it in the first place, I don’t much care. I think the same goes for clicking the “Set Active” on the Payload in the installation.
TCPhelper-2.0.0.urcap (322.4 KB)
Notes:
- Requires Polyscope 5.11
- Considers TCPs with the same translational offset but different rotation values as the same, so might screw up with those. Hopefully that’s like…not ever the case. (Inconsistent return value for TCP rotations) If you enter your orientation as RPY in radians it works fine. This is outside my control due to how the API provides this information.
- Tapping the actual arrow in the dropdown might cause some odd behavior if trying to change the TCP or payload while a program is running. (I wouldn’t advise doing that anyway but hey, that’s just me.) This is because, for some reason, the arrow is not part of the dropdown box, and therefore doesn’t register as “onClick().” Anywhere else in the box works.
