Most of my v8 modules (appear to) work unmodified in v8.1. But changes to the OPC/UA stack broke my two drivers, which have now been updated:
This list will be updated as needed for my other modules.
Phil, do you have usage instances of your Eth/IP module? I started reading through your user manual and we almost exclusively use Allen-Bradley when using Ignition, although we have some customers with Modicon and Siemens. Wanted to see what the target functionality was and if it fits with our use. Thanks!
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.
1 Like