The shaking occurs because the guided transport system is attempting to keep the Moving Unit (MU) aligned with the line, leading to a logical 'collision' between lifting it and its collider while maintaining alignment with the line. This is the reason for the shaking. Using a normal collider to lift it out will not be effective. Why not use a second guided transport, similar to the lift in the demo scene, to lift it out?

Hallo,

wir sind nicht mit diesem spezifischen Problem vertraut, da wir keine direkte Erfahrung mit WinCC haben. Allerdings würde ich vorschlagen, zu überprüfen, ob das Modell in einem reinen WebGL-Build funktioniert. Das können Sie testen, indem Sie im Unity Editor auf "Build & Run" klicken. Dadurch sollte sich ein Browserfenster öffnen, das einen kleinen Unity-internen Webserver nutzt, um die HTML-Seite anzuzeigen. Wenn dies funktioniert, liegt das Problem wahrscheinlich an der Integration oder Kompatibilität mit WinCC. Ich empfehle auch, die CSS-Einstellungen zu überprüfen und zu variieren, da eventuell dadurch die Darstellung in WinCC beeinträchtigt wird.

Gruß

Thomas

Hi Andreas,

This is Thomas from realvirtual. I’m having a bit of difficulty following your current activities and the issues you're encountering. I believe you can achieve your objectives without resorting to scripting.

Here are some key points and basic information to consider:

• Raycast Length: This setting determines the raycast's length for detecting colliders, which is crucial for connecting to guided transports. You may need to adjust this according to your specific geometry.
• Transportsurfaces and GuidedTransports: These components do not perform any reparenting actions.
• Handling Objects: In our tests, we've managed to transfer objects from a TransportSurface and reintroduce them using a Gripper Script. You can refer to this process in our demonstration model located at Assets/realvirtual/Scenes/DemoLoadingUnloadingGuidedTransport.unity.
• Using Multiple Guided Transports: Another approach is to employ an additional GuidedTransport to lift items from an existing one. Check out the example in Assets/realvirtual/Scenes/DemoGuidedTransport.unity.
• Scripts Managing Reparenting: Only the Gripper and Fixer Scripts are designed to manage reparenting and move the MUs out of physical control.

I hope this information is helpful to you.

Best regards, Thomas

Hi there,

We are always happy to help! While we can't create videos for all new hardware and software updates, we highly value the support and feedback from our customers. Could you please provide more details about the specific issues you're encountering with the S7 Connection Tutorial and TIA Portal V19? Basically nothing should be different in TIA V19 or PLCSimAdvenced. This will help us understand your needs better.
Best regards
Thomas

Thanks, we know this issue - it is already fixed - if you need a beta you can get access - otherwise it will be fixed in about 1 week with the next official release.

Hi, do you have the full editor log file - I am sorry, based on what we see we can't tell you what the issue is.

I am sorry we don't have example code really covering what you need.

You can check our api documentation here - there you will find the public properties and methods for example for our drives:

https://realvirtual.io/apidoc/namespacerealvirtual.html

You can also check here how to implement your own interface:

https://doc.realvirtual.io/components-and-scripts/custom-interfaces

The rest is more or less standard c# scripting for a tcp-ip communication. Maybe you can start here:

https://learn.microsoft.com/de-de/dotnet/fundamentals/networking/sockets/tcp-classes

I think the questions are somehow similar to the questions in this post:
https://forum.realvirtual.io/communities/1/topics/654-unity-physics-and-kinematics

Maybe more in detail concerning your problem:

Physical joints are always unstable per se and often only work without oscillations if the fixed update is very small (e.g. 1ms - disadvantage: performance of the model then quickly reaches its limit).

In general: If possible, do not use physical joints. If physical joints are used, then only as a "slave" and the end position is always guaranteed via a drive (e.g. delta pickers, drive for the X,Y,Z position, physical joints for the joints and rods).

I would control the example model myself purely via drives - which are then connected to each other via CAM or GEAR.

Hi Michael,

There are several approaches you can take to achieve this:

1. Position Control via End Element: You can manage the positioning by moving only the endpoint. Although this endpoint is not a real drive, you can connect it to the actual drive using Unity Physics joints. This setup ensures precise endpoint control. While the joints in between might exhibit some shaking, this should not affect the overall functionality.
2. Integrated Drives with Gears or CAMS: Another method involves equipping all joints with drives and synchronizing them through the use of gears or CAMs. This setup mimics the movement based on a "Master" Drive, which aligns with the position of the actual drive. For more details, you might find these resources helpful:
   • Defining CAMs: Defining CAMs Documentation
   • Drive Behavior: Drive Behavior Documentation
3. Using Unity Physics for Kinematics: Employ Unity Physics and Unity Joints (details at Unity Joints Documentation) to handle forward kinematics. In cases requiring purely linear movements, consider using Articulation Bodies (Articulation Body Documentation). Be aware that Unity Physics can be somewhat unstable or jittery, which can be mitigated by reducing the Physics fixed timestep at the cost of performance.

For complex scenarios not involving parallel kinematics, which are typically challenging and unstable with Unity Physics, you might explore using AGX from Algoryx (see https://doc.realvirtual.io/extensions/agx-physics9. This is a more robust solution for accurately simulating complex physics interactions, although it is not free and the definition of kinematics is on my point of view more complicated).

In general, whenever feasible, we prefer to resolve these issues using non-physical forward kinematics, whether it’s a straightforward kinematic chain of a robot or something that can be easily managed with defined cams or gears.

I hope this helps! Let me know if you need further assistance.

Best,

Thomas

Hi, it would be best to implement a TCP-IP interface in C# for realvirtual.io which understands your custom commands and then send for example the drive to a position with the public methods of the drive:

if (commandtype = "motordriveto)

{

    drive.DriveTo(destinationposition);

}

I think this is much better than transferring your commands to a PLC like signal  based control of the Drive.