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.

ok, i think it is because you are compiling il2cpp. For versions before 2022.XX not everything has been compatible to IL2CPP what means that you might need to delete some interfaces or functions. Best in general would be to upgrade to realvirtual.io Professional 2022.XX which has better overall compatibilty. If you stick using 2021 please start unnecessary interfaces. Please also check:  Supported Platforms | realvirtual.io User Documentation

Hi, I checked your approach. 3 robots. First with a Grip Script, Second with a Fixer, Third again with a Grip script and everything works. See video below. 

So I am not sure what the issue has been in your setup. Maybe something with the sequence of the Signals controlling the Grip and Fixer? Can you upload your setup and we will check if we can simplify the process for the user or prevent issues that you encountered.

Unity_910RrXyNLh.mp4

what version of realvirtual.io are you using?

And one question - could you send us your model for checking the wished new function based on your setup. Please send it via https://realvirtual.io/send