I used default settings for both drivers. Concurrency = 2 for Ignition driver, and concurrency = 1 for Class 1 driver
Oy! So it might be more than a 48x speedup if comparing apples to apples. However, I suspect a higher concurrency wasn't helping the IA driver--the response times suggest that it was saturating the Omron's message handler.
I'm surprised that NX is so woeful.. they're supposed to be much better with comms due to separate threads servicing the PLC logic and the comms.
I'll see if i can get a field test for you as well, with the NX701-1600 series.
Is the screenshots of the device overload all you are after at this stage @pturmel ?
I wouldn't call it the NX's fault. Even with my driver, you can really slow things down by using many individual tags instead of arrays and structures, and using any unions or structures with user offsets.
Yes, unless you encounter bugs. Then I would want the diagnostic files from the device's "More... => Configuration" page.
I presume this module can't communicate with PLC5 devices? Don't see mention of them in the manual.
Trying to diagnose some strange connection problems and wondered if this might come in handy for that as well.
No, no PLC5 or SLC500 support at all. Maybe someday.
New Beta is now available:
v2.0.2.230360000 See comment below
Regarding the list a few comments back:
-
Aliases within AOIs work. Turns out that parameter aliases into local tags take on the external access of that local tags, but creating the alias in Studio 5000 automatically switches "None" to "Read Only" for that local tag. That means that many "sealed" AOIs that don't show any of their local tags (and cannot be fixed), do show them to my probe, and any local tags that have readable aliases will also be readable. This doesn't help much for optimization, but much more of the inner values are viewable.
-
Tag alias optimizations didn't make it. There are some alignment nuances that I haven't figured out.
-
Tags JSON that populates the entire processor's tags, using the Types JSON appropriately, is present but not exposed in the gateway. Go to the device's folder in the gateway filesystem if you want to use it. I'm leaving it that way, for now, because any large processor will be crushed if you try to subscribe to everything. And Ignition's memory usage will spike, too. (One of my PlantPax samples resolved to over a million tags. The handful of sealed AOIs made it not optimize very well. Ugly.) Anyways, prune the Types JSON to exclude the members that are unfixably unreadable, and then prune the Tags JSON (if you use it at all) to include only what you really need.
Also: There were a number of other fixes scattered through the module, including for NJ/NX and ML8xx processors.
There is some strange behavior on certain NJ/NX datatypes where writes to members will be acknowledged by the PLC but the data discarded. Similar members in other datatypes work properly, so I haven't figured out a pattern yet. Please report and share details if you run into this one.
Anyways, this beta is way better than the last. Enjoy!
{ Final note: I've decided that the reduced-price license will be simply device count limited, but otherwise have full client driver features. This fits better with future support for Edge deployments. I will be making the client driver Maker compatible, too.}
Edit: clarified #2 above.
3 Likes
Found and fixed an ugly bug today that was causing sporadic disconnections, particularly on older firmware.
v2.0.2.230392053 New file below.
1 Like
With the latest version of the driver I'm not able to browse deeper then two levels below Controller:Globals. This was possible with the EthernetIP Class 1 Communications-2.0.1.230022328-v81 version.
PLC: NX102-1100
EthernetIP Class 1 Communications-2.0.2.230392053-v81 - not possible to expand at pointer
EthernetIP Class 1 Communications-2.0.1.230022328-v81 (1) - can expand all folders
I'm also getting errors on some tags that are working fine with the IA NJ driver: (both last two versions of the Ethernet/IP driver)
See picture, quality is "Bad("Bad_InternalError: An internal error occurred as a result of a programming or configuration error.")"
But values seems to be fine.
New beta. Couple items:
-
Suppressed a super-noisy warning that would flood the logs while connecting and probing and during even the slightest comms hiccup.
-
Significantly reduced memory pressure throughout the module by implementing
SoftReferencecaching forbyte[]andByteBufferinstances, using stepped sizes (8, 12, 16, 24, 32, 48, 64, 96...). The GC can still reclaim them when it needs to, but it makes it possible to skip new object creation when used and released instances are hanging around. This is important when there are hundreds of thousands of OPC tags, as in my lab testing.
I have not yet resolved @helge.rosvik's report.
v2.0.2.230410411
1 Like
New beta:
v2.0.2.230450035
Fixes of note:
- The NJ browsing flaw is fixed.
- An NJ/NX oversize structure read flaw is fixed. { Omron doesn't support partial transfers.
} - More memory pressure bugfixes and improvements. Added Debug & Trace logging to the
SoftCacheabstract class--produces a report once per minute when active. - Fixed a flaw in assembly of multiple items into a larger requests, due to incorrect forecasting of some reply sizes. These would often sneak through without choking if the complete buffer size wasn't being used anyways. There's a new warning to catch these.
There is an outstanding bug in boolean arrays with multiple dimensions nested in Omron structures.
Aside from that, this beta is screaming fast. Helge supplied a test file. I mapped the entire thing into tags, yield this diagnostic:
3 Likes
Ok. Been hacking at this. I have determined that reading an entire structure that has a boolean array in it delivers that array packed into as few 16-bit words as possible, as described in Omron's documentation. This is true for both NJ and CJ alignment for structures.
However, when reading just an array of booleans, of however many sequential elements (greater than one) you request, you get one byte per bit. Not documented!
And when reading single booleans, whether named in a structure or a single element of an array, you get the bit in a 16-bit word, as documented.
It won't be a simple fix.
It does mean that one should never use Omron's boolean arrays outside of structures, and never read them except via the whole structure, to get efficient bit packed transfers.
1 Like
Oooo! I just figured out why the boolean arrays in structures blew up on the sample I got from Helge: the array was a member of a structure that is over ¼Megabyte in size, which made access fall back to individual elements. Oy!
{ Side note: Yes, this is included in the 34414 tags shown in the graphic. Many of the tags are arrays of primitive types, which my module supports. I'm not sure how many tags it would have been without that aspect of my Types.JSON files, but it would be many, many more. }
2 Likes
Well, it wasn't simple. But it wasn't quite as bad as I feared. So, another beta:
v2.0.2.230462332
Now I have to go back through all of my QC files before I'll call it an RC.
I also switched the JSON exports to not use array tags by default. "Compact" versions of the JSON files are placed in the driver home folder if you'd like the original format.
2 Likes
I thought I'd share my worst-performing PlantPax torture test. It contains several PlantPax AOIs that are locked (P_AInAdv is the worst of them), and therefore not completely readable, so that optimization is limited. The IA native Logix driver yields this diagnostic:
Interestingly, it took the native driver about five minutes to stabilize with this large number of tags.
My most recent beta driver yields this:
{ The difference in tag count is due to the extra diagnostic tags my driver offers. }
There are a handful of bad tags with my driver, for I/O datatypes that have inaccessible members.
There are several thousand bad tags with the native drivers caused by AOI local tags.
After factoring in the difference between "Load" and "Overload", there's not quite a 3x improvement.
I do still have beta testers experiencing some problems, but I'm not sure if those problems are in the driver (limited sample material).
I have uncovered some bugs in the designer's convenience tools for the Class 1 driver. As they replicate functionality of the gateway web interface, I won't hold up an RC for these.
3 Likes
Phil,
Is the beta limited to only use the Default tag group?(scan class for us old timers)
I can drag and drop tags and they work great, manually create tags and they work great.
But if I try any other tag group than Default the tags go bad and stay bad no matter what I do?
Am I missing a configuration option or something?
No, should work with different groups. But note that optimization can only occur for tags that are running at the same pace. Do let the optimizer settle for a minute or two after you re-arrange what tags are at what pace.
A quick check in my testbed shows no problem, just a few multiples of the pace to settle.
{ Pssst! I love getting sample files to poke at.... }
Tried multiple ways and let it sit for a while and it still reports back as bad when I change a tag group.
I also noticed that when browsing for the tags the Global tag area is returning as Controller:Globals in your driver when it is usually Controller:Global on the IGN Driver. Not that I think that is the issue, just something different.
Running on an L83, onboard ethernet port, ver 33 firmware.
That's purely cosmetic--doesn't impact the OPC Item paths themselves.
Haven't tested that very much. Will examine, but I don't see how tag group would impact that.
Are you sure you have the desired tag group in the tag provider you are testing? Spelled correctly (case sensitive, I think) ? Try making another, perhaps?