Hi Jeff,

I know NX MCD very well (for example, we did a Simit coupling for the first time before Siemens did it themselves, and we also implemented and sold NX MCD to several customers as a Siemens partner). Nowadays we are completely out of the Siemens business and I don't know the latest developments of NX MCD, but I'll try to give you my opinion about the differences.

This is comparable to NX MCD:
- Import CAD data (via Step or other formats with PIXYZ).
- Define kinematics, kinematic groups, ....
- Define drives (in G4A there are more detailed drive behaviors and you could implement your own with C#, then you wouldn't need Simit).
- Connect the drives and sensors with Simit or PLCSim-Advanced or OPCUA or TwinCAT....
- You have the choice to use Simit or to model the behavior of the sensors and drives in Unity
- Define movements, gears, CAMS
- Moving goods based on forces, transport surfaces and gravity.

What does not work with G4A:
- Measure forces (because of PhysX limitations).
- Moving drives with forces (which mostly doesn't make sense because we need to guarantee the position of kinematic chains, which doesn't work stably based on physics due to a certain spring behavior of the solver) - in G4A we can guarantee the final positions
- Use as CAD system (design is always imported via Step or PIXYZ).

What works in G4A and not in NX MCD
- Distribute your Digital Twin as a fully functional executable to anyone in the world without paying license fees to anyone.
- Distribute it across WebGL, Android, IOS, Linux (one Digital Twin, multiple distribution platforms).
- Create your own UI functions, buttons.
- Use all available Unity features, asset store solutions ....
- Integrate any type of VR, AR with any type of user interaction.
- Render in real-time high quality with live shadows, reflections, real materials....
- Move more than 800 things on transport surfaces (in my time, MCD lost performance very quickly)
- Open source code, documented and freely available C# API.

Best regards

Thomas

Hi Kévin, 

currently we have no solution to support hat. It would require a support of this flexible data definition of the PLCInput and -Output side in Game4Automation and it would need to be implemented into the Game4Automation PLCSim Advanced Interface. There are currently no plans for that development.

Best regards

Thomas

OK thanks, we will include this in our next release

Hi, I don't know how you get the Top-Node ID on your OPCUA servers. With OPCWatch you can check and see it here:

If you leave Top-Node empty it should import all nodes and you will see it in Unity but this might take some time if there are a lot of elements in your OPCUA server.

I am sorry, we don't have any Mitsubishi PLCs here. We are not able to provide any kind of special Mitsubishi related knowledge.

Hmmm, this seems to be a bug. We will need to check on our computers.

Hi, currently we don't plan to deliver any special Mitsubishi interfaces. For the moment only OPCUA is an option. Do you know any special API from Mitsubishi we could use to connect to their controllers?

Hello, S7 200 is not supported. Best regards 

Hard to say where your problem is. But Input and Outputs are working if the inputs don't collide with a real hardware input. If you problem still exists please create a very simple example (S7 project and Unity project) and send it to us.

You can read inputs but if you use S7 TCPIP interface the inputs must be in a PLC memory area where no hardware is configured to. Otherwise the hardware input status will always overwrite what the S7TCP interface has written to the input.