Incredible work
#Free and Open-source warehouse/manufacturing simulator
icy viper
fluid tulip
incredible
stuck grove
Beat me to it. I was a controls engineer for 10 years and had the same idea to use Godot as an industrial simulator.
I developed an Ignition module that could communicate with Godot, and acted as a jumpoff point so that virtually any PLC can talk to the simulator. Only had time for a proof of concept.
Nice to see what you've done here.
Btw; while keeping the core simulator open source, an official third party ignition module would be a nice way to monetize the system. You could probably sell it for $500, and it would get an absolute ton of exposure with industrial partners. Start a foundation and maintain the simulator as open source.
I can give you my code for setting up a low level ignition tag manager that can communicate with a TCP socket on the Godot side, just let me know. Round trip response time is quite low. And you would be able to control the simulator from an Ignition (web, perspective) interface as well - which could have huge appeal.
stuck grove
OPC UA is going to be (surprisingly) slow, unless you do direct reads and writes, to replace the typical tag subscription model that ignition sets up.
An even better thing to do is code an ignition module using this example:
https://github.com/inductiveautomation/ignition-sdk-examples/tree/master/managed-tag-provider
This creates a low level "source" of tags which you can bind however you want. TCP or UDP would be a very low level way to communicate with Godot.
My code is basically just an implementation of that, plus a TCP server in Java and a client in Godot (which is simple)
As per why OPC-UA is "slow". Lots of industries would like sub 20ms round trip time for emulating IO to controllers. Usually this is to emulate (fairly) high speed encoder pulses or servo feedback data.
Ultimately anything that's on the order of a few ms will need to be "PLC" sim only. Different architectures offer different ways to accomplish this
I guess what I'm trying to say is this - you do need to introduce another "middle man" to go to Ignition, then the physical PLC, but windows these days is smart enough to use the loop back virtual ethernet driver, so that packets that originate from the same machine never even go to the ethernet card. You can easily communicate within a ms between Godot and ignition. Then you are just relying on ignition's (proven) drivers to talk to PLCs
The last project I did was using a Godot 3D simulation for a PLC5 system. Kind of shows the power of ignition's built in drivers that I was able to simulate for a controller made in 1997, before the ethernet standard even existed.
As another alternative, you could do ultra low level stuff that's platform specific. Like CIP class 1 comms to an Allen Bradley controller (check out the experimental branches of pylogix)
stuck grove
Very nice. Well all the luck with the project, I shall be staying posted!! When I get some time I will try to tinker with it using RSLogix Emulate.
Libplctag will be great for Allen Bradley and certainly low level enough. Code will definitely run faster than a java module. Are you using GDextension?
stuck grove
There's a great group in #gdnative-gdextension, lots of good advice there on how to build GDextension code. The big advantage is that you can (basically) build onto the engine in C++, but don't have to rebuild the whole engine. You get access to all the same stuff you can access in GDscript. But you don't get the same access to the engine as modifying source code, or making C++ modules for the engine.