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.
1 Like
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.
3 Likes
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.
yes, I did see that about the AOIâs. For that reason, I disabled all the AOIâs temporarily by putting a xic instruction ahead of the AOI command that is not active so it prevents the AOI commandâs from happening. So the issue with the AOIâs is not relevant because they are disabled.
Ok, so when I put the TAg Groups back to subscribe, the MSG utilization goes to a constant 93%. This goes back to my original question, how do I reduce this? With the number of tags shown in the tag groups I mentioned earlier, I would not think this would be an issue with using L81 processor as well. Do you agree? Do I need to configure a couple of more devices and split the tags for each tag group to use a different device?
I tried a test where I disabled top level parent UDT and imported the tags from the PLC. The test was to determine if the nested UDTâs were causing or adding to the issue versus just a direct import of the atomic tags from the PLC. I didnât see much of a change doing this test of the MSG utilization percentage.
Let's see the diagnostics page when you're back in subscribe mode with the full load being tracked.
Another useful thing would be to turn the logger for drivers.LogixDriver.Requests.ReadStructuredTagsRequest to DEBUG and then edit/save the device connection.
Look for "Privilege violation reading struct '%s'; re-optimizing." messages... if you see these then you're subscribed to tags in UDTs or AOIs with inaccessible members, which means you have to read all the tags individually, which is will place a higher load on the PLC.
1 Like
Not following this logic. Disabling the AOI instruction in logic would have no bearing on the Ignition driver still polling the data and choking on the AOI data structure.
2 Likes
Your assumption here is just wrong. The issue with the AOI's is not that the controller is scanning them. It is that they include members which can not be read externally. This forces the driver to have to read the tags in an unoptomized way. If ignition is still attempting to poll the AOI tags, you will still have this issue.
2 Likes
It isn't the execution of the AOI that is the problem, it is simply accessing data in an AOI structure that is the problem.
1 Like
If the AOI is not acted on, then isnât the UDT tags used in the AOI just UDT tags that are not changingâŚbasically? I understand the AOI has a tag structure it requires, but isnât the structure just a series of nested UDTâs?
No. AOI structures are substantially more complicated than simple UDTs, and Rockwell's Data Access manual explicitly tells users to not access them. IA avoids reverse engineering, and basically follows the Rockwell guidance.
I am perfectly happy to go beyond Rockwell's guidance in my own driver.
The other factor is external access to UDT and AOI members. If any member's external access is "None", the entire structure cannot be optimized. This applies to both my driver and IA's driver. AOIs often have such members, and if sealed, cannot be fixed. PlantPax5 built-in instructions have this problem, along with a few Function Block instructions and message instructions and IO data types.
1 Like
As has been stated here multiple times, in the best practices thread, and multiple other posts, youâre not going to find a magic bullet to make your AOI tag structures more efficient. Either accept the performance hit or get busy restructuring them to one of the more accepted practices.
1 Like
I did test today. I collected the information you want with the AOI instructions still in the PLC but disabled and below is the information you wanted. I then removed all the AOI calls and disabled the UDTâs in Ignition that were getting the AOI tag data. This helped a little. It improved things on the Ignition side, but I am still getting MSG utilization percentages bouncing between 77% and 93%. The charts below are after I removed the effects of the AOI commands.
Results after removing AOIâs and disabling UDT for the AOIâs
