Automation Professionals Ethernet/IP Class1 Communications Module 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-configurable tags and structured data types.
In the test project, a couple virtual I/O modules are set up – one to transfer operator push buttons, indicators, and fast-changing status data, and the other to echo timestamped PLC output data back to the PLC input data for round-trip time measurement. The driver “assemblies” specified in the PLC I/O configuration point at tags that mimic the data in the PLC itself, which are then usable within Ignition using the tag names.
The PLC code is supplied for a CompactLogix L24 v20, but is easily converted to other models and versions. The gateway backup is from v7.7.8, but will load into anything that uses the new module signature system. Once installed, update the PLC’s I/O tree to use your real IP addresses, and in Ignition, update the IP address in the “FastUI” device to match the Ignition server’s real IP. Tweak RPI in the PLC to suit your desires. (Set Ignition’s default scan class to that RPI, too.)
In one of my older linux servers equipped with a Core2 Quad 2.66GHz, using two of the four cores in a linux VM, the system just loafs along at ~10% CPU load with RPI set to 50ms. Each client adds a percent or so. Let us know what you get from your setup.
Wider exposure has identified a few more bugs and an application note, so I’m releasing another beta. Highlights:
[ol][li]Updated documentation to include common error codes and typical causes.[/li]
[li]Fixed the default timeout multiplier for scanning (basically, number of missed UDP packets that break a connection): Logix processors use ‘4’ when scanning their I/O. Prior versions of this module effectively used ‘64’, since the actual encoded protocol value ‘n’ is interpreted as 42^n. 42^4 == 64. /-:[/li]
[li]Fixed a gap in Trial mode handling that was missing most trial resets. Trial mode was only certain to be evaluated at module start or when devices transitioned from disabled to enabled.[/li]
[li]Added Logix microsecond wallclock timestamp handling for LINT datatypes. Currently truncates to millisecond resolution passing through the OPC server, but access to the full resolution will be available later. Added a packet arrival timestamp to Assembly objects using this format.[/li]
[li]Fixed an error in OPC subscription handling that would ‘hang’ a subscription item connected to a virtual PLC tag if that tag was edited in the web configuration interface.[/li][/ol]
A note on the sample application’s gateway backup – it comes from a linux install and therefore has a data directory setting in ignition.conf that may not match your platform. If it doesn’t match, the gateway will fail to start after the restore, and the wrapper log will show the directory exception. Please adjust the setting to match your platform to proceed.
Please download a fresh copy of the module and give it a whirl!
The gateway backup is a problem for some people, so I’ve repackaged the demonstration into a plain project file, a collection of XML files, and some detailed instructions to get it all set up. I’ve also created separate downloads for CompactLogix and ControlLogix, with versions 20, 21, 23, 24, and 28.
My modules page has the new information, but you can get it directly here.
Automation Professionals is pleased to announce that the Beta testing period for this module is over and the current version, 1.0.2, is recommended for production deployment. Visit our Module Sales page for the latest versions of all of our Ignition add-on modules.
Among the updates for speed and stability, the module has acquired some advanced scripting and event handling capabilities, and a new Designer interface makes the bulk of the configuration work much easier. (The designer interface lacks a few operations, but is much nicer than the gateway web interface.)
Automation Professionals is pleased to announce the release of Version 1.3 of the Ethernet/IP Class1 Communications Module. Direct download is here. This version adds default tags and assemblies for quick setup as an I/O slave, along with some Multicast UDP fixes for Windows platforms.
We are very interested in using this module. Do you recommend binding the module to a NIC that is used for other communication (e.g. Class 3 communication) or should this module be tied to a dedicated NIC?
On the Ignition side, it should not matter. Note that if you will be using scanner mode (the premium version), it uses only one IP address on the Ignition side. Many I/O devices require multicast in the T=>O direction in order to support Listen Only connections, which means those devices must be in the same subnet as Ignition.
On the PLC side, when the PLC is the scanner and Ignition the adapter (the base version), the connection limits and/or node number limits in the scanning PLC (and comm modules, if any) matter. 1756-ENBT modules are particularly bad. The smallest CompactLogix models also have low limits. This mode does not usually have to be in the same subnet as Ignition, since most PLCs can request unicast in both directions.
I discovered today that function blocks are available for Siemens S7-1200 and S7-1500 processors that implement class 1 scanner and adapter functionality. Documented here:
https://support.industry.siemens.com/cs/ww/en/view/109782314
I’m not a Siemens guy, but I’d love to help anyone interested in testing super-fast traffic between an S7 and Ignition. The scanner function block looks particularly capable. They are both a bit of a memory hog on the S7 side, but might be worth it for snappy comms.