How to cummunicate with an ABB robot through the Externally Guided Motion (EGM) interface?

Hi,

in our current release, we only have an interface to ABB Robot Studio via Shared Memory. Unfortunately, we do not have an EGM (Externally Guided Motion) interface available at this time. You can find more details about our existing ABB Robot Studio interface here: ABB Robot Studio Interface Documentation.

I'm curious if anyone has more information about EGM. Is there a public C#.NET API available for EGM that we could potentially use?

If you are looking to implement interfaces that we haven't covered yet, it's always possible to create your own based on our documentation. Check out the details here: Custom Interfaces Documentation. I also recommend using one of the existing interface C# scripts as a blueprint for developing a new custom interface.

Best regards

Thomas

Dear Thomas,

Hi,

Thank you for your reply and advice.

On GitHub, I have found two examples of conducting communications between Unity and an ABB robot through EGM, as shown below, which are pretty close to what I need. And, just as suggested by you, I'm trying to build a EGM interface based on the C# scripts of these two examples with the help of the C# scripts of the UDP, the ABB RobotStudio, and the S7 interfaces provided by realvirtual.io.

https://github.com/rparak/Unity3D_ABB_IRB_120_EGM

https://github.com/fronchetti/egm-for-abb-robots

My first-step goal is to use RAPID code to control the actual motion of the real robot, and transmit the joint information of the robot in real-time to Unity through the EGM protocol, thereby achieving virtual-real synchronization without feedback control. After achieving this goal, then find a way to solve the virtual-real synchronization with feedback control.

However，I'm facing a rather tricky problem now:

In those two examples, the robot control part and the EGM communication part are mixed in a single C# script. However, in my realvirtual.io scene, the robot control part are realized by the robot-body components associated with the Driven (Script), the Rigidbody, and the Driven_Follow Position (Script), while, the EGM communication part is supposed to be realized by my EGM interface. As far as I know, the connections between my EGM interface and the Driven_Follow Position (Script) component should be some PLC Output Float (Script) and PLC Input Flost (Script) components. But I don't know how to let the PLC Output Float (Script) obtain the real-time joint information of the robot read through my EGM interface. I have checked the the C# scripts of the UDP, the ABB RobotStudio, and the S7 interfaces provided by realvirtual.io. I found that, in the C# script of the UDP interface, there is no special definition is required for the PLC Output and PLC Input components. Integrating the PLC components directly under the UDP interface will be okay, just as shown by the UDP demo. However, for the ABB RobotStudio and the S7 interfaces, some PLC-related statements are necessary in the C# scripts. More importantly, the naming conventions for the PLC components in the three types of interfaces are different from each other.

I'm quite confused about how to communicate between my EGM interface and the robot component through the built-in PLC components in realvirtual.io. Hope you can give me some further adivce about how to configure the PLC components with a custom interface in realvirtual.io.

I didn’t fully grasp the details of your question, but I’ll try to provide a short explanation using the example of PLCOutput Floats, which are typically used for drive positions like robot axes:

• Signal Import Function: Interfaces usually have a signal import function to retrieve all signals. This could involve importing a CSV file or directly communicating with the PLC, depending on the interface.
• Signal Creation: The interface checks whether the signal already exists under the interface. If it doesn't, the signal is created. Note that no signals are automatically deleted. This is just like we handle it. You could also assume that all needed signals are manually created as a children of the interface.
• Special Interfaces for Robot Axes: For robot axes, there are specific interfaces where we directly set the Drive.CurrentPosition using the interface. In such cases, the interface somehow knows how the signal for the current axis position is named and has a list of all Robot Drives.
• Standard Method: Typically, for robot axes, Drive.FollowPosition is assigned to an interface signal like PLCOutputFloat.
• Core Task of an Interface: The primary responsibility of an interface is to communicate with the partner system (e.g., via EGM in your case). After receiving the values, it sets the values in the signals, such as assigning Signal1.Value = receivedValue. When sending it is the other direction: valuetosend = Signal2.Value;
• Data Conversion: Some data conversion might be necessary between different data types, depending on the interface.
• Parallel Threading: Most interfaces require some "overhead" for parallel threading. This allows the interface to communicate as quickly as possible in a parallel thread, ensuring it doesn't block the Unity main thread.
• PLC-Specific Statements: We don’t have specific PLC-related statements, but each interface may differ in how the data is transferred and encrypted.

Future Plans: We might add an empty blueprint to an interface in a future release but this will take some time. This would allow you to simply enter the specific communication part

For the moment, you should use any of the existing interfaces as a blueprint and delete everything what is PLC / interface specific.

Dear Thomas,

Hi,

Thank you so much for your reply.

The "Core Task of an Interface" you have mentioned can be realized by the C# scripts provided by the example on Github, as shown in the pictures below. I think it works like the way "Special Interfaces for Robot Axes" you have mentioned, (but I'm not for sure). However, what I would like to do is to use the "Standard Method" you have mentioned together with my EGM interface. You said that "For the moment, you should use any of the existing interfaces as a blueprint and delete everything what is PLC / interface specific.". What does "delete everything what is PLC / interface specific" mean? Did you mean that I should delete the PLCOutputFloat and PLCInputFlost components under the GameObject of my EGMIterface (e.g. the "joints[1]" components in the picture above)? If so, does it mean that I actually can hardly do it in the "Standard Method" way for now, because it would be a rather complex and systematic renovation of a realvirtual.io interface? If so, the way of using "any of the existing interfaces as a blueprint" will be something similar to the C# scripts provided by the example on Github, right? 

Due to my unfamiliarity with Unity and the C# language, I have some difficulty in clearly understanding the structure and principles of the project in Unity and the existing interface scripts of realvirtual.io. So, sometimes my questions may be quite silly. If that's the case, please accept my apologies. Thanks again.

Dear Thomas,

Hi,

Thank you so much for your reply.

I'v finished the EGM interface based on the UDP interface of realvirtual.io. And here is my first Digital Twin of an ABB robot. 

Reavirtual.io is really awesome~ Thanks a lot~

Digital Twin ABB.mp4

Perfect - congratulations - in the end it looks like you did the interface pretty quickly.