Appreciate your efforts on this Phil!! 
BTW, what ever happened with that NX processor you were playing with?
The "test out your driver" project kind of got lost in the nether as the focus shifted to actually getting some plant code written.
I notice you've made a lot of updates to the driver since i last tried it and had issues, so i might try and give it another go over the break.
On a slight tangent, i'm curious, how does your drive deal with this annoying datetime issue with the way Omron PLCs expose the date?
My driver supports all of the Omron date and time types. IA's tag system tends to smash the submillisecond fractions.
Do note that Omron PLCs are utterly brain dead in regards to time zones. If you don't put the PLC in UTC all the time, you will suffer.
FWIW, we did get an issue made for that. I think we're just going to change the validator to be [-24, 24]. I think the original range was probably just somebody looking up the UTC offsets and seeing they range from -12 to +14.
1 Like
I deliberately did not put an offset into my driver. I strongly recommend using UTC in the PLC. Use a derived tag to apply offsets if one must. 
I didn't want to either.
1 Like
Speaking of that, one of the things I did last week before the release candidate was to make my driver spit out its NJ browse results in tab-separated format for consumption by the IA driver. I was comparing my driver against the native one and noted that mine was only ~30% faster on one sample. Then I recalled that Sysmac Studio had warned me that it had excluded a couple tags from the CX-designer export. When I looked, I realized that, for that specific sample file, those two tags were ~90% of the data.
I'm pretty sure it was because the structure type had ENUM elements scattered through it. Anyways, putting the non-enum tags back into the IA driver put the performance difference back at the ~15x mark.
I don't put a link to the TSV file in the web UI, but it is dumped into the device's data folder with the rest of the diagnostics.
1 Like
oh man that is great, i truly despise having to manually manage the "not exported' tags via some other text file... Omron really needs to sort that out, as i believe it is a hang over from the export tool being primarily used for importing into their Omron NB HMI panel projects or something.
Of course, if you switch to my driver, you don't have to manage it at all--it is browsed. (And I support the ENUM tags, too.)
1 Like
I have been playing with a UDT of sorts that reads some sort of raw time (EPOCH seconds currently at least is correct in the NJ) that the UDT then also has a proper datetime exposed for Ignition use that is converted as a sort of derived tag.
The other aspect is that i find it fairly painful to have UTC times in the PLC when trying to monitor the realtime value and have to somehow convert that into "localtime" in your head.
How do you tend to manage that? Just don't look in the PLC? 
EDIT: Having PLC as UTC also makes synchronising its clock harder no?
Just look at the Ignition tag from that item through my driver. Ignition will localize it.
I wouldn't think so. NTP is all UTC, so if the PLC knows it is UTC, it should "just work". And you never have to worry about daylight savings time changes.
Automation Professionals is pleased to announce a beta release of the Keyence KV-8k support mentioned above.
For Ignition v8.1+: v2.1.11.240102103
This implementation reads the model code to initialize the span of the various types of device memory, and for KV-8000+, reads the function version to conditionally expand the R device range. All models with built-in EtherNet/IP (KV-5500 and above), models that accept the KV-EP21V comm module (KV-3k & -5k), and the models that accept the KV-NC1EP comm module (KV Nano) should all work with this driver.
Notes and known issues:
-
My lab unit (KV-8000A w/ function version 2.7.01) tends to randomly chop off the EtherNet/IP connection for unknown reason(s) -- channel just dies for 30-60 seconds at a time. Sometimes every couple minutes, sometimes runs for tens of minutes.
I'm collecting info for a bug report to Keyence, but packet captures just show it ceasing to respond. (With and without KV Studio monitoring--with no matching interruption.) -
There is no support for reading non-mapped named global variables, and it is unlikely to become available. What Keyence implemented with their symbolic access is just an alias to a range of mapped registers, exposed as an array of WORDs. Nothing larger than 496 bytes, and no exposed structure types. Intended for simplistic use with other PLCs message instructions only.
-
Keyence did not implement the EtherNet/IP "Multiple Request" service that allows multiple small operations to be assembled into a larger, more efficient packet. So while the unit allows 4000 byte message buffers, its largest message is ~460 bytes, and they cannot be packed.
-
Once running, on physical LAN, packet handling can run close to 2 requests per millisecond. So the computing hardware itself is no slouch. Keyence has left a lot of performance on the table, so far.
-
Most memory areas in these processors are split between global and local usage, with the boundary configurable. The exposed span is the complete range, but accesses beyond the boundary will be rejected.
3 Likes
Hi Phil Turmel,
EtherNet/IP Communications Suite driver module sounds interesting for a project that I am on.
Please, let me notice if the beta still available to test the viability for a future purchase.
Regards.
Hi Pedro,
All of my modules work with Ignition's native 2-hour trial mode, so you can verify suitability for your needs. Unless you need the Keyence support, you probably should start with v2.1.10, not this beta.
Latest Production Releases are always linked here:
Further application notes:
-
For some reason, Timer/Counter preset and accumulator values are transferring in reverse word order on my KV-8k, contrary to the docs. (But the words are little-endian as expected.) Don't trust them.
-
The Keyence device memories get their own top-level node in the OPC browser:
- The individual memory types expand in chunks to minimize scrolling, and for word areas, expand to include common data type transforms:
-
String conversions are planned....
-
Documentation updates are planned....
2 Likes
Hi Phil,
Our project with 90,000 tags pulling from one PLC is experiencing the overload issue, and we will have more systems in the near future. And yes, we are using a lot of custom AOIs in the PLC, and we bring in most members from the AOIs directly into Ignition for read/write.
I believe your module will be a game changer for our problem. I do have a few questions about using this module, and someone probably already has asked this before, but if we were to implement your module, do we need to modify the OPC tag path for the PLC tags at all? Does it have any impact on the Ignition OPC read/write?
Thanks!
No, same OPC Item Path syntax for controller items. (Well, strictly speaking, my module's item syntax is a superset of IA's native driver. I have additional features.)
There are some diagnostic items that my module doesn't implement, and some extra diagnostic items.
That’s great. Do we have a trial period to test out this module or we do need to purchase it and test?
Thanks!
All of my commercial modules honor Ignition's normal two-hour trial mode. Test in that format first, please, to verify functionality for your use-case.