I’m working on a project with 7.6 at present that has in excess of 50,000 tags; around 15,000 are Kepware OPC tags. Kepware was running on its trial licences and so needed resetting every two hours, when this happened I noticed that some tags on fast scan classes (250ms) would become stale on the restart and would only become good if I did something to the tag or the tag scan class. I also noticed that if the tag value changed then the tag would become good. I checked Kepware with a separate OPC client and didn’t see any problems. Making more scan classes and distributing tags has solved the problem and leads me to my questions.
Assuming each scan class processes each tag sequentially there must be a point where the class cannot process all the tags in the time allotted, what happens? Is the time extended or does the scan stop and just restart at the beginning? Is there any way to see if is becoming full for its time period?
Is it good practice to have many scan classes even if they have the same scan time? do they process in parallel?
I’m just trying to get a fast efficient system and would like to understand in detail the dynamics of scan classes
Chris
I don’t think you actually need to worry quite yet - the behavior you’re experiencing with static tags in fast classes not getting their values sometimes on initial connect, a restart, etc… is a race condition bug we fixed in 7.6.2.
Now… if you’re experiencing this in 7.6.2 then maybe we’re looking at another problem 
Splitting your tags up into whatever logical groups and scan classes make sense for your project does make troubleshooting a little easier, when it comes to that, but performance-wise I think you’re ok either way.
Kevin
It seems we both do a little work on Sundays,
I think it’s running 7.6.1 r2 or r3, I intend to update this coming week. Once done I’ll see if there is an improvement.
With 7.6 alarming, it’s easy to allow the user to select the severity of an alarm, we use an engineering popup template with drop down selectors for each alarm component. I’m tempted to place the “severity” tags in a separate leased scan class, am I correct in thinking that the scan class will run fast when any window with a tag in the class is open but will go slow if not even though the tag in use for alarming. I was thinking 60,000ms and 1,000ms would be suitable scan times
Chris
I’ve checked today and we are running 7.6.2 rc4
I’ll update and see what happens, but to repeat my first question
“Assuming each scan class processes each tag sequentially there must be a point where the class cannot process all the tags in the time allotted, what happens? Is the time extended or does the scan stop and just restart at the beginning? Is there any way to see if is becoming full for its time period?”
thanks
Chris
[quote=“Powerplan”]
“Assuming each scan class processes each tag sequentially there must be a point where the class cannot process all the tags in the time allotted, what happens? Is the time extended or does the scan stop and just restart at the beginning? Is there any way to see if is becoming full for its time period?”
thanks
Chris[/quote]
The executions of the scan class will start to ‘stack’, basically meaning it’s running constantly and now executing slower than its intended rate.
On the Execution tab of the Console on the gateway you’ll find an entry in there for the SQLTags scan classes where you can take a look at the execution stats.
Thanks Kevin, I’ll look in the morning
Chris
While I’m thinking about scan classes,
if I have a tag that is in a leassed scan class, I understand that it will change to the faster rate when being viewed in a client.
Now if that tag is used in an expression tag that has a faster scan class will the leassed scan class:-
Run fast all the time?
Run fast if the expression tag is viewed?
Only run fast if the leassed tag is viewed?
Chris
Hi,
Leased tags are “leased” any time there is something subscribing to them. The usual case is on a screen, but references through expressions also subscribe. So, a tag would be leased, and run at the fast rate of its scan class, when referenced in this way.
Note that the rate of the expression tag has no effect on the referenced tag. The only exception, as you could imagine, is when the expression tag itself is leased, and the “slow rate” is 0. This means “don’t execute” when not leased, and will cause the expression tag to be uninitialized when not viewed, which will in turn remove the subscription to the other tag, which may cause it to no longer be leased as well.
Hope this helps,
Thanks Colby
we have some sites where we collect data over 3G and scan every 30 seconds and I’m looking to see if I can improve the user experence by using leased tags
Chris
Colby
I looked on the gateway at the scan classes, I feel a bit foolish, my slowest completion time is 36ms for my largest scan class, the small fast ones are 3-4ms.
I sometimes forget about the information available in the gateway
IS there anyway to access these times and values as tags.
By the way, useful info on Leased tags today
viewtopic.php?f=70&t=10959
Chris
Hi,
There is an important aspect to remember, however, about scan class execution time: In subscribe mode, that time does not include the time it takes to retrieve the data from the device. Subscriptions are asynchronous, so the values come in as available, based on the requested rate provided by the scan class. The scan class execution time is how long it takes to go through all of the tags and evaluate the values that happen to be there for alarms, events, etc.
When using subscriptions, and potentially slow devices, the better place to look would be the “diagnostics” link next to each device in the device edit page. That will give you information about request/response times.
If you use “read” mode, the scan class time will include how long it takes to actually perform the read. Generally though, especially if using leased scan classes anyhow, “subscribed” is better, as it lets the driver optimize things a bit more.
Regards,