I finally got around to doing version 2.0 of the Modbus library I maintain, and in the course of developing a more usable server API than the 1.0 version had I figured it would be useful to "dogfood" the API.
This isn't an official IA module. Aside from some unit and integration tests I've done some cursory poking at it, but nothing like the QA it would receive as an official module, so caveat emptor. It may have more value simply serving as a more complete example of how to use the Device API.
It will require some changes to be 8.3 compatible, I'll make an 8.3 branch that demonstrates the necessary changes and how to do config migration (whenever we are "public" or "beta").
If your drivers still use the Driver interface, however, this is not at all representative of the amount of work you have ahead of you. The Driver interface is no longer public in 8.3, and the extension points supporting them have been removed. All drivers must use the Device interface.
I don't think it's actually all that hard. Just different method signatures and implementations of what are otherwise the same core concepts: browse, read, write, subscribe
Amazing !
I think I have a usecase, perhaps out of scope
We have an existing application from another scada that we convert to Ignition.
This application is connected to some modbus PLC, and those PLC accept only one TCP connection.
We would like to connect Ignition to the PLC on the same time to be able the check both HMI have the right data.
Perhaps we could connect Ignition to the PLC with the Modbus client driver
and connect the other SCADA to Ignition Modbus server.
Do you have planned to "connect" this module with ignition modbus client driver to be able to share the data ?
Other SCADA (master)
|
Modbus TCP
|
Ignition (master and slave)
|
Modbus TCP
|
PLC (slave)
You could accomplish that now with some tag change scripts, not sure what it would look like to try and do it automatically.
If you don't mind a little programming a better solution might be to use the Modbus library I linked and build your own "Modbus TCP to TCP Gateway"... it would be pretty trivial I think. On one side you maintain a single client connection to the PLC, on the other you receive as many Modbus TCP connections as you want, and you just proxy/pass the requests on down to the slave. Could be wrapped up and deployed via docker in no time.
The most straightforward implementation would, yes.
You can get as creative as you like, though. If you know ahead of time all the registers that both SCADA systems will read then your gateway could read them at whatever pace you define, update a cache, and then server the incoming client requests out of that cache. Lots of options.
Or can you just weave it all together with the server driver
A complete implementation of your use case with my alternate driver is shown over here:
Does not require double tags. Optionally takes advantage of the common address patterns between the IA driver and my server driver to minimize the configuration required.
One of its users has precisely the same motivation as you: expose a device that accepts only one connection to multiple consumers.
This is huge. As Phil said, there are a lot of devices that only accept one connection, if I want to do some investigation or diagnosis, I have to stop the Modbus driver before I can run program like mod scan. I lost production data in the meantime.
Also thanks for the byte order option!
