Omron NJ Driver performance optimization

Hi,

I’m still trying to improve performance between my Omron NJ PLC and Ignition.
The current procedure for populating the Omron NJ Driver tag table is outlined here:
https://docs.inductiveautomation.com/display/DOC/Omron

Currently if i do an export from the PLC, I end up with ~18000 tags in the driver.
A lot of these tags are actually not required to be read or written by Ignition. But since they are part of a UDT structure in the PLC, they all get exported and added to the driver.

If I took my tag export from the PLC, and manually removed say 8000 tags not required for Ignition, would that help the driver cope better? Ie: Does the driver poll all tags in the driver, or only tags that are requested from Ignition OPC Server (tags built in Ignition)?

Also is there an optimal way to build structure the tag members in a UDT in the PLC? Should tags required for Ignition be grouped together? Is there any performance difference if the HMI tags are interspersed with non-HMI tags?

Ignition only polls tags that are subscribed to. There’s no negative impact (other than some small amount of memory) when you import all the tags. It just makes them available for browsing.

The NJ doesn’t implement the necessary services for us to browse tags or learn about the UDTs so the driver has to address and read each tag individually (as opposed to reading the entire structure). Because of this I don’t think there’s any benefit to rearranging your tags, but I couldn’t tell you definitively.

The reality is that the NJ’s EtherNet/IP implementation is not very good in the case where you need to subscribe to a lot of tags.

Kevin, is there any roadmap ahead involving doing any improvements to the NJ driver? It’s at the point now in the project where plant is going to start getting livened up and we are still not happy with the performance with the number of tags we have. And we’re actually going to be needing to add about 70% MORE tags to the system.
Is it possible to engage in a discussion with someone from Inductive Automation about this?
Cheers.

Sometimes there’s not a good answer within a traditional query/response driver. Before you panic, though, try creating multiple driver instances pointing at the same PLC. Spread your subscribed tags amongst those drivers. If performance doesn’t improve, you’ve hit the PLC’s query/response communication limits. (Omron might have suggestions for that, corresponding to an Allen-Bradley’s communication time slice.)
If you still need more/faster traffic, you might need Ethernet/IP class 1 communications, also known as producer/consumer tags and I/O connections. This solution requires compatible code and data structures in your PLC, so your PLC coders have to be involved. UDP packets at high data rates will put extra CPU load on your Ignition server, but the results can be impressive.
The module is still technically in beta, as it lacks some user-friendly configuration tools, but it performs well. I don’t have an Omron NJ to test with, so I can’t offer a demonstration kit, but you might find the AB demo I created helpful.

Thanks for the response Phil.

I’ve increased the concurrency in the device settings to start with. I think there has been some improvement but only time will tell. Is there any way to determine the max value i can bump this up to? (currently at 8)

I intend to test multiple devices too, if i can’t get any love from this.

That module might be worth a shot, but definitely a last ditch attempt, as we’ve already done all the work in the PLC with UDT structures (I’m the PLC coder) and i fear that this might be quite a demanding thing to try in terms of man hours (which we have few of).

If your UDTs are under 496 bytes each, or can conveniently be broken into chunks that fit, you can fairly quickly add buffer copies to send the data to the output buffer of virtual I/O modules. When the packet arrives in my module, the assembly can be configured to place the data in the right place in a matching UDT tag within my driver. The PLC UDT tag will then be replicated in my driver, with the same apparent structure, and updated at the RPI you set in your virtual modules.
Then you can point your SQLtags at my driver’s copy of the data, instead of querying the tags through the regular driver. The downside is that you can’t write to these tags. (Well, you can, but they get overwritten by fresh packet data every RPI, and they don’t go to your controller.) To get data back into your controller, you need to set up input buffers in the virtual modules (really fast, but different PLC code to use it), or always write to these tags via the regular driver using system.opc.write*().

I have noticed considerable improvement in performance by adding another Omron NJ Driver device, and pointing it to the same PLC.

Also, the PLC’s Ethernet Card that is used to communicate with Ignition was under a 4ms task. Moving this to a 100ms task also helped improve comms considerably. I imagine Ignition was trying to query a lot of data from the PLC and the PLC just couldn’t service the comms at such a high speed.

3 Likes

2 posts were split to a new topic: Omron NJ Performance Issue