I certainly cannot regenerate a complete L5X--I throw away all the tasks, programs, routines, and controller properties.
But a feature to export all the raw data completely--maybe. (That's how this used to work--suppressing billions of zeros is the new-fangled design.)
Can we use system.device.addDevice to add an EtherNet/IP Class1 Host Device?
Are the keys documented anywhere?
You cannot, effectively. There's no way to supply the required configuration XML.
I have to rework this for 8.3, so it will be possible at least by then.
Automation Professionals is pleased to announce a new production release of this module. Highlights:
Fixes another regression in L5X import/export related to clashes between Rockwell predefined types and ODVA CIP type names.
Fixes gateway configuration of controller-scope tags with non-Rockwell features, like non-zero-based array dimensions.
Fixes long-standing regressions in Designer-side live editing of Host Device instance data types and controller-scope tags.
Adds Designer-side live editing of program-scope tags and program-specific code modules. Previously only configurable with XML import of the entire Host Device.
For Ignition v8.1+, as usual: v2.1.17.241411841
Side note: Adding/removing program scopes in a Host Device instance is still only possible with XML import. This functionality is planned for a future release--certainly by v8.3, as the wicket editors in the gateway are going away and will not be replaced (as such).
Note that if you do use non-Rockwell features in your tags and/or data types, expect external systems using a Logix driver to choke when browsing that Host Device.
Hey Phil, can you please give an example of a non-Rockwell feature?
Rockwell array tags can be up to three dimensional, but all subscripts begin at zero. Rockwell UDTs may have array members, but only single-dimensional, and still zero-based.
Omron and Keyence (and others, I think) support three-dimensional arrays for both tags and UDT members, and all of those dimensions can have a non-zero starting subscript.
Lots of odd differences with booleans, and boolean arrays, and UDT member alignment, and large variances in support for ODVA's elementary data types.
Automation Professionals is pleased to announce a new production release, fixing an uncommon bug in Scanner mode connection breakage handling.
For Ignition v8.1+ as usual: v2.1.18.241701138
The reporting client's environment takes multiple days of operation to show the flaw in question, which required a lengthy QA period to achieve confidence in the fix. I did not replicate the bug in-house, but the client's report was sufficiently detailed to allow static analysis to expose the flaw.
Automation Professionals is pleased to announce that this EtherNet/IP driver suite is now available for purchase for Ignition Edge, with a steep discount. See Automation Professionals' updated Module Sales Policy here:
https://www.automation-pros.com/Module%20Sales-2024-11-05.pdf
Automation Professionals is pleased to announce a new production release, fixing another hard-to-hit bug in Scanner mode connection breakage handling.
For Ignition v8.1+: v2.1.19.242671936
This fix, generated a few weeks ago, has been simmering in the reporter's production environment to confirm the solution.
All users should upgrade.
Does this driver support Modbus TCP?
No, but I have a separate driver that does:
Trying this driver out with an Omron NX102. Having a strange result where I can read the tags in the OPC quick client and get a result and good but in the designer tag browser I get 'BAD' value for the same ones. This is happening for many tags and structures but others are fine.
Please send the diagnostic files from the device's .../data/opcua/devices/ folder to my Support Email.
I don't have an NX in my lab to work with.
I'm running latest version of the communication suite (2.1.19 (b242671936)) on a 8.1.44 gateway and occasionally we get
One-shot task com.automation_pros.enip1.GatewayHook$1@5ef56951 threw uncaught exception.
in our logs with a stack trace of just
java.lang.NullPointerException: null
Both the gateway and module are running in trial mode as this is our dev/testing gateway. The module currently has 1 device defined as a CipClientDev with no tags configured at this time (we have been flipping between this and base Ignition driver)
From what I can see, this error appears in the logs around the time when:
There are a few cases where this seems to occur randomly or at least whatever occurs around the same time is not in the logs.
Is there any other place I can look for information to be able to send you to help narrow down the cause of the issue?
Please add this (with unique index in place of .8) to your ignition.conf:
wrapper.java.additional.8=-XX:-OmitStackTraceInFastThrow
That will yield a proper trace for that NPE.
Added that line to the conf and now I can't get the exception to happen 
.
Maybe the server just needed a restart. I'll keep an eye on our logs for the next few days and hopefully it will pop up again.
Ha HA! I managed to get the module to throw the NPE again.
Stack Trace:
java.lang.NullPointerException: Cannot read field "modules" because "this.sys" is null
at com.inductiveautomation.ignition.common.script.ScriptManager.createLocalsMap(ScriptManager.java:699)
at com.automation_pros.enip1.GatewayHook$1.run(GatewayHook.java:239)
at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$ThrowableCatchingRunnable.run(BasicExecutionEngine.java:550)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
I'll keep an eye out for any others that have a different reason listed.
This one seems to have been caused when I saved a change to an inheritable project's library script. This NPE was among a list of 'Restarting gateway scripts'
Huh. That's not my code.
Or rather, code I run on a 500ms delay after my hook gets an initializeScriptManager() request can find the manager instance is bogus at that point.
Will fix. (More defensive code.)
Automation Professionals is pleased to release a new BETA of this module. It is nearly functionally identical to v2.1.19, but more importantly, is a full conversion from the deprecated Driver interface to the modern Device interface.
The core conversion used in the Client option is the same code I used in my Modbus driver, so the diagnostics now follow the SamplingMetrics interface instead of the PollingMetrics interface.
The conversion of the Host and Target devices of the Adapter option was much more involved, and I took the opportunity to clean up some technical debt, unifying the address parsing and OPC datatype mapping across the entire driver. A happy side effect is that the Host and Target devices now support accessing one-dimensional arrays (and final dimensions of multi-dimensional arrays) of primitive numeric types as actual OPC arrays. Matching that existing capability of the Generic EtherNet/IP client.
Ryan's bug above is not yet solved.
This beta passed my internal QA just a little while ago.
Please test!
For Ignition v8.1.7+: v2.1.20.250362234
Now I can focus on the new config model in v8.3. Oy!