@Kevin.Herron I did the test and received no errors. I’m inferring that an error would mean that UDT’s could not be read as a whole and then would be read an element at a time. So this is not happening here. Correct?
Also, here’s the total points and requests.
If I’m interpreting @pturmel’s comment correctly, 6060 tags are being read with 401 requests. Which also implies that UDTs are being read as a single unit. Correct?
The issue remains that the PLC is swamped with comms requests.
PLC with device disabled.
PLC with device enabled.
When we were under the impression that elements were being read individually, we did a few things in an attempt to improve performance.
First, we removed any elements from the UDT that we did not need to display or historize. Based on my new understanding, this would not have any effect. Is that correct?
Second, we packed status bits into integers, again thinking fewer elements meant fewer transactions. Again the actual effect of this is probably negligible.
Lastly, we put elements that didn’t change often, such as configuration parameters in different, slower scan classes. Would this actually make performance worse, if those elements are now being polled separately?
The current situation is that we are trying to get 213 UDTs from the PLC at a rate of 1.5 seconds, and the PLC is not able to deliver this.