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

I haven't had the chance to dive deeper into your requirements for extending the grip and fixer functions yet. I understand that working with RealVirtual can be a bit challenging, especially when you're in the process of learning it without a training or project support from our side.

I do have a question regarding your setup. My initial approach would be to create a grip script for the robots and assign the fixer function to the turntable. This approach should ideally work right out of the box as far as I understand the necessery process. But yes if you would do it like that, you would not have the direct integration into IKTarget.

Regarding your question:

• The Grip function is typically the active component (like robots, etc.) and is controlled by a signal.
• The Fixer function, on the other hand, is usually passive. It’s primarily used for securely fixing objects without requiring a controlling signal. The way it works is simple: when the Grip opens and the part is inside Fixer's area, the object is fixed. When the Grip closes again, the object is gripped and the fixer is releasing it. Essentially, Grip manages the control, while Fixer, in the end, just somehow glues the component to a fixed place.
• For the ease of use we integrated the Fixer function into the IK functions. But I did not checked your setup to use a grip on the other side. Will need to do that.

Thanks for your proposed changes but currently I am not sure if this is working in all other cases. I would need to make a deep dive into int.

Hope this helps! Looking forward to your thoughts.