So, my Ethernet/IP module has two quite different use cases:
- The original case is to make an Ignition Gateway function as a virtual Remote I/O chassis that AB Logix processors could include in their I/O tree. (Or from any other brand that can scan E/IP remote I/O devices.) I/O protocols are far more robust than typical SCADA request/reply protocols over TCP/IP, so this approach alleviates the primary cause of momentary pushbutton misery. While reducing UI latencies on Ignition UIs to near-hardware levels. This thread describes in more detail:
- The other use case is direct communications with Ethernet/IP I/O devices, bypassing any processor. This requires the premium version of the module to enable I/O Scanner functionality. These topics are examples with Balluff IO-Link Masters:
http://forum.inductiveautomation.com/search?q=ethernet%2Fip%20bni
The key advantage in either case is that the Ethernet/IP I/O protocol, aka "Class 1", is a UDP transport that does not stall on dropped packets. (Also applies to producer/consumer tags, which my module also supports.) You can reliably run a Requested Packet Interval of 100ms with Ignition, and usually 50ms or even less (very load/CPU core count dependent).
I should also point out that my module can be an I/O "slave" for many scanning processors simultaneously--just allocate different assembly numbers and/or virtual slots. And can be a scanner for isolated I/O while also being a slave for other scanners.