Hi @jbm ,
I first add TCPs (let say “Bob” and “Paul”) of my own through the JAVA API. Then I am trying to override the TCP before using the “UserDefinedRobotPosition” to define a waypoint in this TCP. Once the waypoint is accepted, I store the value in the contribution DataModel and reset the TCP to the one the customer set as Active (let say TCP_1).
To do so, I override the tcp using “set_tcp(Bob_values_as_pose)” function in urscript via the secondary client socket port 30002. Once that is done, I call the UserDefinedRobotPosition to set the waypoint.
Here is my problem, sometimes Polyscope shows the interface with the right TCP (“Bob”) and sometimes not (TCP_1).
Adding textmsg() to my script to get_tcp_offset() validate that my set_tcp() command as work properly.
It does the samething with the “robotMovement.requestUserToMoveRobot()”
Why is that not consistent? Am I doing something wrong or not?
Thank you!
Hi @j-p.royer,
It should be consistent. But please keep in mind that other process can set the active TCP as well. Each time a program is started Polyscope will set it to default.
Are sending the secondary program just before the other method? If that is the case you might also be struggling with some timing challenges.
Best regards
Ebbe
Hi @Ebbe thank you for your fast response ,
I confirm that the script method has been sent and execute before using the Java API.
Which process can set the tcp back to default if timing is ok?
By “Each time a program is started Polyscope will set it to default.”, you mean that the one that I set become the default one?
I sent it as a primary program through the secondary client. Is that ok?
Thank you!
Hi @j-p.royer,
My concern is not that it is change in the short time from you sent the “set_tcp()” script. But with the call you have changed it in URControl, but Polyscope might not have read it back from URControl yet. The primary interface is running 10Hz, so if your script is changing the active TCP it might take Polyscope up to 100ms to be updated.
Ebbe