I am on a new install and am beginning to have communication response times between Ignition and 4 Compactlogix PLCs with V24 firmware. The best response time is 1 second , ie. when I press a button something happens and the worse response time is 3 seconds, same thing, press a button and something happens.
Ignition is sitting on its own VM with a separate VM to handle the database and another VM to handle OPC-UA communications. Attached are screen shots from 3 plcs at the VM for OPC-UA communications, but i do not know how to read this data. Can someone explain what these mean and do the values look OK?
The numbers to pay attention to are the latency percentiles and the rates.
Latency is about how long it takes to get a response back from the PLC and the rates are a measure of request throughput.
Let’s look at the first device:
144 requests @ 1500ms. In a perfect world, that would mean your average throughput is ~96 requests/s. Looking at your one/five/fifteen minute rates, it would appear the driver is only managing ~67 requests/s. Why? Look to the latencies. 98th percentile… 143.5ms. Not good. I imagine the only reason you’re managing 67 requests/s is because you’ve got your concurrency level set to between 8 and 10? Is that right?
For what it’s worth, in 7.9 we’re going to overhaul these (as well as pretty much anything else status/diagnostic related). I realize they’re not intuitive and if you don’t know what you’re looking for they’re useless.
[quote=“Kevin.Herron”]The numbers to pay attention to are the latency percentiles and the rates.
Latency is about how long it takes to get a response back from the PLC and the rates are a measure of request throughput.
Let’s look at the first device:
144 requests @ 1500ms. In a perfect world, that would mean your average throughput is ~96 requests/s. Looking at your one/five/fifteen minute rates, it would appear the driver is only managing ~67 requests/s. Why? Look to the latencies. 98th percentile… 143.5ms. Not good. I imagine the only reason you’re managing 67 requests/s is because you’ve got your concurrency level set to between 8 and 10? Is that right?
For what it’s worth, in 7.9 we’re going to overhaul these (as well as pretty much anything else status/diagnostic related). I realize they’re not intuitive and if you don’t know what you’re looking for they’re useless.[/quote]
Kevin,
correct , i have concurrent requests set at 8 , I will drop back down to 2 and work from there. So the goal is to get the percentile #s lower?
Also look at the tasks in the PLCs. Logix processors have a communication time slice setting that can make a big difference when scanning many tags. Even better is to not use any continuous task in the processor. Change the continuous task to timed, with a schedule that makes sense for your application. For many cases, that’ll free up substantial communications bandwidth.
The ultimate goal is to have your throughput be as close to expected as you can get it.
Like Phil said, the best place to start is in the PLC. Unless you’re communicating with these devices over a remote network or VPN or something, what’s probably going on is that none of they PLCs have enough time dedicated to communications.
[quote=“Kevin.Herron”]The ultimate goal is to have your throughput be as close to expected as you can get it.
Like Phil said, the best place to start is in the PLC. Unless you’re communicating with these devices over a remote network or VPN or something, what’s probably going on is that none of they PLCs have enough time dedicated to communications.[/quote]
Phil,Kevin,
thank you for the responses. My issue is I am not in control of the PLCs only the SCADA side. We were bought by our main competitor last year , and they have the ‘Big Box’ automation company mentality, where the PLC programs are tested and are a standard not to be modified. They have have made the same mistakes I have seen other ‘Big Box’ automation companies follow, mainly a Compactlogix with only 1 Ethernet adapter expected to handle communications with Ethernet IO, Ethernet VFDs, PLC - PLC Ethernet communications and Ethernet SCADA.
If this was my design, I would have had each PLC be a Contrologix each with 1 1756-ENBT for Ethernet IO, 1 1756-ENBT for MCCs and 1 1756-EN2T for SCADA communications.
It may not event be the ENxT that is overloaded, but the processor itself. There’s only so much time given to explicit messaging, and even that varies with whether the task(s) are periodic or continuous and what the timeslice is.
The new L8x controllers have significantly improved explicit messaging capabilities. My understanding is that there is now a separate CPU that handles communication duties.
[quote=“Kevin.Herron”]It may not event be the ENxT that is overloaded, but the processor itself. There’s only so much time given to explicit messaging, and even that varies with whether the task(s) are periodic or continuous and what the timeslice is.
The new L8x controllers have significantly improved explicit messaging capabilities. My understanding is that there is now separate CPU that handles communication duties.[/quote]
As a follow up to this, i was on the job site today and had the programmers increase the Overhead Time Slice from 20% to 50% and response time went from 3 - 5 seconds to almost instant response. The overall task cycle time only increased by 3 ms.
[quote=“Curlyandshemp”][quote=“Kevin.Herron”]It may not event be the ENxT that is overloaded, but the processor itself. There’s only so much time given to explicit messaging, and even that varies with whether the task(s) are periodic or continuous and what the timeslice is.
The new L8x controllers have significantly improved explicit messaging capabilities. My understanding is that there is now separate CPU that handles communication duties.[/quote]
As a follow up to this, i was on the job site today and had the programmers increase the Overhead Time Slice from 20% to 50% and response time went from 3 - 5 seconds to almost instant response. The overall task cycle time only increased by 3 ms.[/quote]
