I don't think that there is a way for doing this. It is also a little bit "against" the simulation logic. Markes can't be read from external devices in real systems. You could use S7 interface maybe instead.

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

Hi,

If you're unfamiliar with Unity and C#, I highly recommend learning the basics first. Implementing an interface without this foundational knowledge would be very tough.

Regarding the suggestion to "use any of the existing interfaces as a blueprint and delete everything that is PLC/interface-specific"—what I meant is that you should reuse the C# code (the one script) of an existing interface and remove everything that's specific to that particular interface inside this script. However, doing this requires a good understanding of C# so that you can navigate and comprehend the code.

The parts you remove need to be replaced by C# code tailored to your custom interface (in your case, EGM, where you seem to have some examples on Github). 

That said, simply copying and pasting code won't work in my opinion. You need a decent level of C# knowledge to properly implement and modify a custom interface.

Best regards

Thomas

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.

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.

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

Hi Mike,

I checked, you are right, the arrays have not been updated in the Inspector List of OPCUA Node. We will publish this with an official update next week. Will also extend the documentation for arrays.  I will send you with a private message a full OPCUA Update including an example how to read an array with code by subscribing to it.

Best regards
Thomas

Will check it this afternoon on my computer. 

Don't know why the array is not imported on your side. Can you try manually setting the array Nodes like this:

Eigentlich sollte über die AssemblyDefinitions SharedMemory für Android ausgeschlossen sein. Vom Pfad her scheint es sich um eine ältere Version zu handeln. Um welche realvirtual Version handelt es sich. Notfalls einfach den Folder realvirtual/private/Interfaces/SharedMemory löschen.