Hi, 

did you use the function Parent Drive, please check our demo scene under Assets/game4automation/Scenes/MovingTransportSurface.unity where a rotating transport surface is done. 

The Transport Surface has to be in parallel (not as a children) to the rotation drive. And in Parent Drive you need to reference in the Transport Surface to the Rotation Drive. This is necessary due to some limitations in Unity Physics. A "IsKinematic" movement can't be combined with a physical movement (like the transport surface) in a hierarchy.

We don't need it there because the CAD users don't have AML exporters in the project (and even not the kinematic information in the CAD) - so STEP and defining everything in G4A is fine for our current research project (as well as for most of our users).

I think there are two main reasons why AML is so uncommon:

- very complicated format (specification is hard to understand even for myself....)

- there are no exporters available - this is main reason why nobody is using it and there are no importers)

My favorite would be to define an open and easy standard like a JSON together with a Step CAD export. The simple JSON export would be easily implemented by macro programming in most CAD systems. If you are interested in this we can cooperate - we have first drafts for it but so far nobody who implements the CAD macro.

The focus in our research project changed, AML is not needed any more, so an official AutomationML interface is not planned any more. In general I am missing very much the availability of AML exporters for common CAD systems. As soon we see, that there affordable standard exporters available (besides the very special solutions for automotive) we will change our mind. But you are free to develop your own importer - it should be not to much work because reading in XML and Collada into Unity should be very easy.

Hi Pablo,

thanks - I will send you a beta today or tomorrow. Maybe you can check with the beta if the problem still occurs. 

Best regards

Thomas

Hi, 

FMI could be the future standard for behavioral model exchange, but currently it seems that you can't get FMUs of any component from the OEMs. And I'm pretty sure that you can't export FMUs from Simit, for example, and that Siemens doesn't provide FMUs for their own drives (Siemens is interested in selling Simit, not replacing it ;-)). Currently I would not rely on FMUs to replace own behavior models. Unfortunately, I don't see an industry accepted standard being available anytime soon. If you are a Simit user and have your own behavior models, then you can continue to use them and Simit along with Game4Automation.

I hope this helps, even though it may not be the answer I was hoping for.

Best regards

Thomas

Hi, I am in vacation until this Thursday. I think it will be best to look first into your project and to check. You can send us your NDA to info@game4automation.com and I can sign on Thursday morning.

Best regards

Thomas

Hi, you are deploying to which destination platform. Which version of G4AProf are you using. Can you share your project so that we are able to check?

Please try both - latest OPCUA4Unity and the version before. We replaced the full OPCUA basis library in latest release.

The colliders of the MU are not defined as they should. You can compare with the MUs in the Demo scene.

You need to have at least one box collider on an MU which is on the layer g4a_MU (see my sceenshot). This layer is working for transport collissions as well as sensor collissions.

Please also check:

https://game4automation.com/documentation/current/physics.html

The example MU in the demo scene is even more complicated. It has two colliders - one for the transport (like realistic rolling on the bottom - on the layer g4a_TransportMU) and one for the sensor on the layer g4a_SensorMU.