Setting Up Virtual Controller in Robot Studio For EGM

[jbeck28]

Hello,

I've seen some talk in other issue threads about running a virtual controller in robot studio on a Windows PC, and connecting to this virutal robot through EGM to test functionality. I am however, having a very difficult time connecting to the virtual controller on the windows machine. When I open the flexPendant in robot studio and check the network settings for the controller, there is no connecting for WAN, the only thing I see populated is service port, but that IP cannot be pinged from the Linux computer I'm attempting to run an EGM driver on.

Do you have any tips on how to properly set up a virtual controller for networking?

Thanks, Josh

[jontje]

Hello @jbeck28,

The WAN and service port network settings shown in the virtual FlexPendant are not used in virtual controllers, so you can ignore those.

For me it's usually enough to do something like this:

1. Set the virtual controller's EGM system configurations (i.e. IP address to the Linux computer and the port to use)
   • See RobotStudio --> Controller tab --> Configuration --> Communication --> Transmission Protocol
2. Check that the computers can ping each other
3. Verify that the Windows Firewall isn't blocking the UDP communication (e.g. add rules to allow UDP communication on the ports specified in 1.)

[gavanderhoorn]

And:

4. whenever you need to "connect to the robot" use the IP address of the Windows PC running RobotStudio.

[gavanderhoorn]

As this is not really an issue with the library in this repository, I'm going to close it.

We could potentially consider adding a section to the readme (or some other part in the documentation), but in the end this seems like a general usage question in the context of RobotStudio, not abb_libegm (ie: all interaction over a network connection with a virtual controller requires the same steps and/or approach).

That doesn't mean this is a "stupid" question btw, nor that I'm dismissing this as irrelevant.

And of course: feel free to keep commenting.

[jbeck28]

Thank you for the quick reply, jontje. This has clarified a lot. I have gotten RWS to grab whether the motors are on, rapid is running, and whether the robot is in auto mode. I have no however, gotten EGM to connect. I'm using the EGM samples you linked to in a different issue thread (after changing the Cmake file so they compile against the pure cmake version of egm), and c3_joint_velocity_controller_node just hangs at "Wait for an EGM communication session to start..." and nothing changes on the flexPendant.

However, when I try to run the driver that I typically use (when I have a robot), the virtual flexPendant will show "Start joint mode", note I'm using stateMachine add in version 1.0. At the same time, the commenandegm_interface_->isConnected() returns false.

After a short while the virtual Flexpendant says "No data from the UdpUc device"

I've almost certainly configured something incorrectly on the Robotstudio side. In the transmission protocol page should both ROB_1 and UCdevice have the same IP?

Thanks again for all your help.

gavanderhoorn, perfectly reasonable to close this, I apologize for starting this discussion as an issue when it clearly wasn't an "issue" from the start. I did not know where else to get help on this particular subject, but saw in the documentation that it was mentioned to test things via simulation before moving to an actual robot. I'm not entirely sure that any explicit directions need to be added to the documentation. Perhaps if I ever get this working (and you think it would make a nice addition) I'll submit a PR for this, as it may help someone else out in the future.

[jbeck28]

I just figured it out... shame that took me almost all day. Both ROB_1 and UCdevice need the same port as well. In my case 6510.

[gavanderhoorn]

@jontje: perhaps we could add a sort of FAQ or hints section to the readme, or a separate doc, which could list some gotchas.

Even though it's all documented in the EGM documentation, the basic IRC5/RW6 documentation and the RobotStudio documentation, having to go through all of that just to get things working may be a bit much.

On the other hand: I'd not be comfortable if people could start using EGM -- which I don't consider beginners functionality -- without knowing how to configure their robot or how to work with it. I've had this with other robot drivers/interfaces, where users had no experience with the robots or controllers, and started (or tried) to use the tutorials as a substitute for experience and/or proper training.

@jbeck28: this is not directed at you of course.

[gavanderhoorn]

I apologize for starting this discussion as an issue when it clearly wasn't an "issue" from the start.

No need to apologise.

Better to open an issue and have it closed with the suggestion to ask your question somewhere else than never asking questions.

I did not know where else to get help on this particular subject,

So technically I would say this would be a generic question about EGM and how to use it/set it up in RobotStudio, which would seem like something you'd post on the ABB RobotStudio fora.

[jontje]

Sorry for the slow response @jbeck28, but here are a few clarifications even if you have already gotten it to work.

I've almost certainly configured something incorrectly on the Robotstudio side. In the transmission protocol page should both ROB_1 and UCdevice have the same IP?

The Remote Address attribute needs to point to wherever your EGM server is located, so that the robot controller knows where to send the EGM messages. And it is the RAPID code that specifies which of the ROB_1 and UCdevice transmission protocol instances that are actually used during runtime.

I just figured it out... shame that took me almost all day. Both ROB_1 and UCdevice need the same port as well. In my case 6510.

The Remote port number attribute depends on the port number specified in the EGM server (for example, in your case in the c3_joint_velocity_controller_node's source code).

[jontje]

@jontje: perhaps we could add a sort of FAQ or hints section to the readme, or a separate doc, which could list some gotchas.

Yes, that would be good @gavanderhoorn

If I remember correctly then you have mentioned Sphinx before, and I guess that could be used for a better "Getting Started" documentation etc.?

[gavanderhoorn]

We could use Sphinx, or just a separate markdown doc for now.

I'd first focus on content, we can change / upgrade the delivery system later.