We have 100+devices (primarily AB CompactLogix) connected to our system and well over 50,000 tags and over the years we have done things just to get something working. The result is a somewhat messy system. I was considering trying to clean things up a little and was considering using scan classes to help do that. Right now we the “default” scan class is our most used and likely 70%+ of the tags are on default. I believe that will cause issues in itself since the scan class will never get through all the tags in its 1s poll time. So I was considering a set of scan classes for each device. This would end up with likely 500 scan classes. These would be a couple of standard polled classes, maybe a drive class, and a couple of leased. This would also allow me to adjust each devices poll rates without fear of affecting another part of a project utilizing a different device.
What I don’t want to end up doing is slowing performance to make things “seem” more organized. Has anyone done anything like this, and was the result good or bad? Or is there a better way that someone knows of?
Well… the first thing you should understand is that when it comes to OPC tags, “scan class” is a misnomer.
We are not literally scanning/polling every tag on a cycle - basically only the rate of the scan class is used as a parameter when creating the OPC subscription and monitored items.
When it does matter is for things like DB tags and expression tags (particularly those that call runScript), where they do affect the execution time of a scan class.
Knowing that do you still think you need to reorganize everything for performance reasons or just because it’s nicer to work with an organized set of tags and scan classes?
This might be a bit too simplistic--the OPC client is just setting up a subscription, but the driver behind it is going to (try to) poll at that rate.
Yes, that's true. But he doesn't need to worry about the entire scan class "getting through all the tags in a 1s poll time". At least not because of OPC tags.
Hi,
In my company we have one project per production area with separate tag providers.
Then we can manage tag groups in one tag provider/project without interfering other part of the system.
We also name the tag group as they are configured, eks Leased 1sec or Direct 5sec.
1 Like
Knowing that do you still think you need to reorganize everything for performance reasons or just because it’s nicer to work with an organized set of tags and scan classes?
[/quote]
Okay, so performance reasons may be out, I read some old posts from quite a few years ago that made me believe there would be a performance hit (tags not getting refreshed when they should) because of the quantity of tags attempting to update at the same time. This makes me feel a little better about my hoarding of tags under the default scan class. I still need to organize better and get my tags communicating more efficiently.
Thanks!
You do need to be mindful of performance and sometimes you do need to use a variety of scan classes per device, but it doesn’t sound like you’re seeing issues right now. It usually manifests as obviously slow tag updates or even intermittent bad quality tags.
50,000 tags from 100 devices in the same scan class is just an organizational problem. 50,000 tags from ONE device in ONE scan class is where you might start to see performance issues and decide which tags really need to be polled fast and which ones can be slowed down (and possibly where leased scan classes can start to be used).
Yes, I am seeing issues, and that is/was part of organizing. By organizing and adding scan classes per device i was hoping to find all the loads and balance the scan classes to reduce my comms overhead on these devices. I get tag timeouts quite often because the tags are all at default when for example, the hmi push buttons only need to be leased.
Thank you very much for your input.