# Automation Professionals' v8.1 Module Updates

**URL:** <https://forum.inductiveautomation.com/t/automation-professionals-v8-1-module-updates/40804>\
**Category:** 3rd Party Modules\
**Created:** [November 19, 2020, 4:08pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-v8-1-module-updates/40804 "2020-11-19T16:08:26Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [November 25, 2020, 2:52am UTC](https://forum.inductiveautomation.com/t/automation-professionals-v8-1-module-updates/40804/3 "2020-11-25T02:52:18Z")

</div>

So, my Ethernet/IP module has two quite different use cases:

1. 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:

> [@Snappy user interfaces with the Ethernet/IP Module](http://forum.inductiveautomation.com/t/snappy-user-interfaces-with-the-ethernet-ip-module/12617):
>
> Automation Professionals [Ethernet/IP Class1 Communications Module](https://www.automation-pros.com/modulesales.html) has been in beta for a few months with no recent issues. A release to production use is approaching soon and I thought I’d share a test project and its matching PLC code I’ve been using to exercise the module’s base features. In the simplest setup, this driver presents a virtual I/O chassis to to the outside world, populated with up to 100 virtual I/O modules – I/O modules that also appear to be ControlLogix processors with user…

1. 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](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.

---

_[View the full topic](https://forum.inductiveautomation.com/t/automation-professionals-v8-1-module-updates/40804)._