I did try and it is better. Class 3 utilization ranges from 15 to 57% with 1 concurrent connection. Request count is slightly lower.
I have been combing through the forum on this particular problem but have not been able to resolve my issue. I have a Rockwell Processor (L81ES) that is reporting via its web page diagnostics, a MSG (Class3) utilization bouncing between 38% and 99%. On the PLC end of things, I have one UDT that is communicating to the Ignition server. This parent UDT has 13 other UDT's, 5 BOOL's, 5 DINT's and 5 REAL's configured. The 13 child UDT's will have
combination of other BOOL's, DINT's, REAL's and UDT's. The number of nested UDT's doesn't go beyond six levels. And it isn't at every UDT. The six level just represents the worst case.
On the Ignition side, I have one device configured to communicate to the PLC. I have played around with Max Concurrent Requests...going from 2 to 5. I have also played with the CIP Connection Size from 500 to 4000. Neither seemed to have an effect on the MSG utilization.
Below is how I have the Tag Groups configured with the number of tags associated with each tag group.
Originally, all the groups were set to Subscribed for the Data Mode and I was pegged at a constant 93% on the MSG utilization. When I change the Poll Mode to the above, this is when I would see a jumping around of between 38% and 99%.
I disable the Device connections, the MSG utilization drops to a respectable 16%. I have disabled the first level UDT’s starting with the last and working up the list of nested UDT’s. It took about half of the first level UDT’s to be disabled before I noticed a significant change in the MSG utilization would drop to a max of 68%. Now granted, the lower half of first level UDT’s (when looking at the Tag Browser) amount to about a third of the total tags. I would think the number of tags left and the scan rate could be handled easily with an L8x processor.
I had a few UDT’s on the PLC side going directly to to/from an AOI. I disabled the rungs with calls to that AOI, but again, not much of a change to the MSG utilization. When you look at the Device connection, this is what I see.
Any suggestions on what I can do? This application is being used for an HMI to a servo system, so I really don’t want to change the scan rate of the Tag Groups I have. Will creating a couple of different device connections going to the same PLC help? I have looked at the forum topic called
“Ignition & Logix Best Practice Tips for better communications”, but what I have tried really hasn’t helped much.
Are you pointing at any members of AOI tags? Or include AOI data structures within your UDTs?
If so, try my alternate driver. Also make sure that all members (params, local tags) of the AOIs have at least ReadOnly external access.
Do you include any I/O data types within your UDTs?
If so, don't do that, as it scrambles optimization for the entire UDT. If you can avoid accessing any such I/O data at all, do that. If you must have it, consider making a UDT with the same structure as the IO type, and using CPS to copy live data to the optimizable type.
I’d keep your tag groups in Subscribe mode. Polled mode doesn’t change the performance and has a big downside in that it’s not counted in the device diagnostics.
1 Like
As an update to your questions
Are you pointing at any members of AOI tags? Or include AOI data structures within your UDTs?
This is a snippet for the PLC program. The top level parent UDT is the UST called HMI. All communications between the Ignition project and the PLC go through this UST.
Do you include any I/O data types within your UDTs?
This is a snippet from the controller tags. The other UDT’s are very similar to this.
I had the worst MSG initialization percentage when all the tag groups were set to subscribed. It was only when I changed them to poll mode I got better MSG percentage values. They bounce around like I said, but under subscribe mode, it was a constant 94%.
Yeah, you are pointing IA's driver at a huge AOI. Performance will suck.
Looks like part of PlantPax. If PlantPax v5, then performance will suck using anyone's driver, as those objects are unfixably unoptimizable. (Even Rockwell's proprietary methods will choke on this.)
If PlantPax v4, and you have access to the source (unsealed AOIs), then you may be able to fix this to be optimizable with my driver (won't help the native driver). PlantPax commonly includes I/O data types directly in AOIs--you would have to re-engineer those, too.
In your review of the Best Practice topics, did you not notice the warnings about PlantPax?
Probably because Polled mode tag groups are scheduled fixed delay, not fixed rate, and your poll is taking significantly longer to complete than the tag group rate, meaning you were getting a "break" between polls of whatever the group rate was, as opposed to constantly polling because you're constantly behind.
1 Like
TIL. Thanks.