I have a project where the customer is insisting on removing communications gateways (Modbus/TCP to DNP3 or Ethernet/IP) and instead using ignition to convert all Modbus data into DNP3 and Ethernet/IP so that it may be read/written by a parent SCADA system and Allen-Bradley PLCs.
The read data will sent to Ignition via Modbus, then perhaps scaled or changed, before it gets written back into external end point tags via a different protocol (DNP3 or Ethernet/IP).
The control or write data will be sourced from either SCADA or the field PLCs, then sent to Ignition via their parent protocol, then Ignition will perhaps again scale or change the data, before it is sent back to the Modbus devices via Modbus/TCP.
My understanding is this is not a preferred application of Ignition for large amounts of data that needs to be historized/monitored, used for control, and robust. Also, I know with rockwell PLCs the class 3 communications could easily get saturated when reading and writing to and from Ignition.
In general, I don’t see Ignition being used as an intermediate communications gateway between two points of control. Can someone provide their insight on why this should or shouldn’t be done?
I want to instill in the customer the need for the stand alone class 1 communication gateways so that Ignition could serve as a control point for the PLCs and the the PLCs could interface with the class 1 gateways to talk Modbus or DNP3 to the other devices. Any loss of communications to the Ignition server would not alter the control of the plant since the PLCs are driving the logic to the other devices.
I think you are confusing Ethernet/IP with the logix protocol. Ethernet/IP is what AB PLCs talk to IO systems with. It has Class 1 and Class 3 comms modes, and is probably what the existing gateways use. That means the gateways are likely in the hardware tree in Logix5000 and the data is mapped as tags directly.
Ignition and HMI devices talk a different protocol to AB PLCs that has browsing access and single tag request capabilities, but is not a time sensitive protocol.
Ignition will likely walk all over the gateways in features and speed as well as usability.
Ignition will not be part of the hardware tree in EIP unless you use third party drivers.
AB PLCs only have so much network processing, so regardless of access type, comms is limited.
On this point, once all the tags are getting fed through Ignition, it makes it very easy to delete the legacy SCADA that reads from Ignition and replace it with a nice clean Ignition installation for likely much less cost and much better maintainability. It makes upgrading the systems on site much easier.
I'd use my 3rd party drivers to both access and expose Modbus and EtherNet/IP resources, and use my Integration Toolkit's tag actions to push data around.
Any data to and from Ignition would be communicated as a Class 3 message in an Allen-Bradley PLC regardless, right? And for 30+ modbus devices each with a few hundred integers of data, that would easily saturate the maximum rate of class 3 messages in most processors? Using a stand alone gateway would allow me to bring in modbus data as a class 1 message which has alot greater bandwidth than class 3, as you know.
Not necessarily. My driver can function as an EtherNet/IP I/O adapter or scanner (class 1), and as a virtual PLC (class 3 target), optionally as a I/O scanner (class 1) or with producer-consumer tags (also class 1). The fixed buffer layouts of class 1 traffic are much lighter loads on the PLC.
My alternate client driver also perform better than the IA native Logix driver for some specific cases. You should look at this topic and its various related links: