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.

I think we need the model for checking what is going wrong.

Zur genaueren Analyse bräuchte ich ggf. noch das gesamte Log. Kommt hier eine hilfreiche Meldung bereits davor? Es sieht so aus, als ob der TwinCAT HMI Server die Verbindung komplett schließt, warum auch immer. Userrechte ist immer noch mein Verdacht oder generelle Verbindungsprobleme. Da unser Wissen auf der TwinCAT Seite und auch die Testmöglichkeiten sehr beschränkt sind, ist es schwierig für uns herauszufinden. Ich weiß dass ein Kunde sowie auch Beckhoffselbst das Thema am Laufen hat. Ggf. wäre es hier notwendig auch den Beckhoff Experten mit einzubinden, um die Beckhoff Seite sicher richtig konfiguriert zu haben. Ich muss allerdings mal Fragen, ob ich den Kontakt weitergeben darf.

You're absolutely righ.

But changing this might involve more than just a single script, and ensuring that it doesn't interfere with existing functions is quite challenging. For example, the current data structure in MU and the full logic is built around the concept that a part can only be gripped by one component at a time. This design choice does make sense since it ensures that the part follows the component precisely.

We’re considering a larger reengineering effort to overhaul the entire fixer grip functions. However, that's going to take some time.

In the meantime, the quickest and most effective solution for your situation would be to create your own entirely separate function, rather than altering the existing one. Here’s what I suggest:

1. Copy the Scripts: First, make a copy of our scripts.
2. Relocate Them: Place these copied scripts outside of the realvirtual.io folder.
3. Create Your Custom Function: Develop your own custom grip function based on these scripts.

This approach should help you achieve your specific goals without risking any unintended side effects on the current system.

In the scenario you described, it seems that the MUs are being simultaneously gripped by two different components. This isn't supported or intended behavior. Typically, when something is gripped or fixed, it becomes a child of the gripper or fixer, following its position. If Gripper A moves while Gripper B is still gripping, there’s a conflict—who will control the movement?

This is likely why your case 3 isn't working. Such a setup could lead to unexpected behavior, potentially causing collisions or damaging other elements that rely on the Grip/Fixer system. I recommend developing a custom gripper tailored to your specific needs to avoid these issues. But we are taking this into account if we think  about reengineering Grip or Fixer in the future.

I will also extend our documentation to make sure that it is clear that gripping one part by two Fixer or Grip is not supportet.