Activate/Deactive Remote Control via Computer

Dear URCommunity,
Is there a way to enable/disable remote control from a socket communication?
For example, I have an app that requires to be in remote control but also needs to be out of it so it can run properly, and I don’t want to use the teach pendant in order to change it.
Best regards,
Pedro Monforte

Hai @PMonforte ,
As far as I know, I don’t think that is possible because toggling from remote to manual mode require privilege access(password). So the mode changes are just possible from the teach pendant only.

Take a look at the dashboard server here: https://s3-eu-west-1.amazonaws.com/ur-support-site/42728/DashboardServer_e-Series.pdf

You can change operational mode using this. (Short guide here: Dashboard Server e-Series, port 29999 - 42728)

Thank you Eric for your advice. However, I had already tried that and it does not allow me to switch between manual and remote control (only between manual and automatic), and this is precisely what I need.
I appreciate your reply anyway
Best regards,
Pedro Monforte

Hi !

Only auto and manual mode can be change with the command " set operational mode XX "

Remote and local control can be check with the command " is in remote control " but it’s not possible to change to remote control with a command, it’s can only be done on the teach for safety reason.

We had the same issue on our system with a virtual teach. We set a fault if we are not in remote and operator must open the virtual teach to change the mode.
.

Hi Pedro,

I got aware of your post and got happy reading it. I had the same problem a while ago and posted it in here. Unfortunately, it isn’t possible to get back to “Remote” after changing the operational mode to “Manual” (or “Automatic”).

If you only need to switch from “Remote” to “Automatic”, you can do that without passwords needed. If you really need to switch back to “Remote” and think this should be a MUST (as me), then please vote up for my post in the second link ("Wish: Switch…).

Hi @yann.devisscher @PMonforte

facing the same “issue”.

My Robot is connected to a PLC. They are communicating via Dashboard Server.
What happens now, when someone switchs from Remote to Local mode and then back to Remote, its killing the
communication between the PLC and the UR. If i try to send signals the Robot answers “…not connected to Port 29999”.

I have to deaktivate and activate again the communication (from PLC to UR). Only then the Robot will accept again commands from the PLC.

Which is super annoying. If someone changes the operation mode on the Robot and doesn´t deaktivate and then activate the communication on PLC, the whole system is messed up…

Trying to get an answer/ advice from UR since weeks. But didn´t got any feedback/answer so far…
That´s a bit frustrating…

Greetings from Luxembourg!

Thank you everyone for your replies. However, I have managed to solve the problem. The real reason I needed it to be in manual mode was to be able to use the freedrive mechanism (remote control does not allow it). I then realized that I could send a script which would activate the freedrive even if in remote control.
Best regards,
Pedro Monforte

Could you share the script? I would be very gratefull, since this was also my motivation for the opertion mode switching.

Best regards,
Yann Devisscher

Th full script manual can be found here: https://s3-eu-west-1.amazonaws.com/ur-support-site/115824/scriptManual_SW5.11.pdf
Just Ctrl+F for freedrive. The script manual is an amazing reference for unlocking potential with the robot you might not have known you have access to.

Thanks. I just didn’t try it that way, since I though the robot should be in “Manual”-mode beforehand. Good to know it works.

You can do it with Remote Computer Access.

I am not sure if you found a solution to this or not. But I am just now finding the same problem. I am able to program a solution using dashboard server commands. I send the normal commands (power on, close safety popup, brake release, and if brakes don’t release I know that it was switched from remote to local and then back again. I then re-init the tcp connection, and then try the previous commands again. but it works the second time

Hope this helps someone