Difference between grip (script) and fixer

After writing my question I got an idea. Griping and fixing work now with the following changes in the fixer script.

1. 

This change stops double list of Mus in MUS Entered.

2. 

Now the fixer can fix Mus even if they are fixed by a grip script.

Please verify if this changes are okay and please take a look on my first question above.

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.

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

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

Thank you for the quick support.

I real machines there is always this moment when parts are gripped by two components.

For PLC program tests it could be necessary to test what happens if the handing over doesn't work out (e.g. sensor failure). When process of home positioning is started it can happen that the part should stay at the first gripper. This isn't possible currently but I think it should be possible to achieve that by extending the Fixer/Grip/MU scripts. I haven't found the solution yet tho.

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.

I understand that and will solve it as you have described.

If I find a good way to solve this I will let you know for your consideration.

Best wishes

Andreas

Hello Support,

thank you for the video and the support in this case.

This thread is corresponding the my other thread "Handing over MU between two grippers".

I think I need to clarify what I want to achieve a bit more.

Yes I wanted to use the Fixer function which is implemented into IKTarget.

So the robots are using Fixer to pick/place the MU and the round table is using Grip.

The RT gripping is controlled by PLC and the robots gripping is usually (as far as I know) controlled by the robot program itself in real machines. To me the new fixer function in IKTarget seemed to be created right for this case.

I am not sure why I needed to make the changes in the Fixer (script). But without the changes I couldn't make it work. The robot couldn't pick the MU with the fixer function in IKTarget while the MU was gripped by the Grip (Script).

Ofcourse I am sending you the project.

The bigger and physically unlogical problem is handing over between two grippers/fixers.

1. Gripper A is gripping/fixing the MU.

2. Now Gripper B is also gripping the MU. The new parent for the MU is Gripper B now.

Now we are testing home positioning process by PLC program. 

3. Gripper B opens gripping. Gripper A is still gripping the MU and now the MU should change parent to Gripper A.

But currently in simulation the MU is just falling down / not in parent with Gripper A.

I couldn't find an easy solution yet for this by editing Fixer/Grip/MU scripts.