We are using a socket connection (port 30001) to change in live the TCP and the payload mass with the urscript function “set_tcp” and “set_payload_mass(3.0)”. We are in v3.10 (23/05/2019)
We are using an offline programming software to command the robots.
We would like to check on the teach pendant that the robot takes in account the information sent.
We have thought to use the functions :
But when we are using these functions in a program run on the robot, the variable values do not change :
I think when we are running the program , the installation values are taken in account and overwrite the mass and tcp, so we don’t see our socket modification.
Do you see a way to overpass that, and to get the mass and tcp information taken in account by the robot?
Thanks for your help.
You’re correct the payload may be getting set as an active payload, but when you run your program to query with get_target_payload() it will pull from the installation file.
I know that the primary and secondary client stream the TCP offsets, so you can parse through the stream as shown here: How to process package from robot controller
Unfortunately there currently isn’t any built in method for reading the active payload as you described.
You can also try setting the payload in a thread on polyscope instead, the thread could get updated from a variables passed in using a RTDE interface, or other external sources. When the payload is set in the same program that is querying the target payload, you will read the active payload.
Thank you for the answer !
An other answer from one of your colleague :
It is normal not to see the result of the functions like get_target_payload and alike when sending these commands using a client interface.
The reason for this is that when you send those functions they do return a value but they return it to the program running on the robot not on the socket you opened, just the same way the work when you call them in a program, that’s why you don’t see anything in return.
In order to retrieve this value there several possibilities:
- Send an assignment using the client interface. If the command sent instead of “get_actual_payload()” were to be “global my_var = get_actual_payload()” a variable that stores the value returned from the function would be created. In so doing, even if the variable is released at the end of the program, in this case a one-command program, a package on the primary interface is sent. Please refer to the excel sheet at the end of the following article:
At the end of the primary interface you’ll find several messages sent on the primary interface, among them GlobalVariableSetupMessage and GlobalVariablesUpdateMessage. If you parse these messages correctly you should be able to retrieve the correct value.
- Write the results somewhere readable, an output register or the log file