Has anyone explored the possibility of dynamically changing a tag’s scanclass? Initial use case would be something like “I need to scan this tag once every 10 seconds while it is being controlled by my running sequence, but while my sequence is not running it only needs to be scanned every 10 minutes.”
The first option I can see would be python code and a call to system.tag.editTag, but I’d like to avoid the tag re-evaluation that comes after this system call, especially if there are alarms on the tag that could potentially re-trigger.
The second option I can see would be using a driven scanclass that is driven by some expression, but given that there could be a large number of tags that all need to have scanclasses changed at different times, I don’t think this is a viable option.
Is anyone aware of some existing functionality that would allow a scanclass to change automatically?
Yes, driven scanclasses/tag groups 
. You can make as many as you want, e.g. one per process/line - even if they're otherwise identical. Yes, it's somewhat more boilerplate, but it's going to be significantly more performant (and less headaches down the road) than trying to script tag changes or something else convoluted.
2 Likes
Driven scanclasses is an option, but in Clayton’s example above, I could easily see a scenario where one could determine that each tag needs its own scanclass to get the required functionality in the sequence. If this becomes the standard practice, then the number of scanclasses might get quite large and hard to manage.
If you’re going to be controlling these processes in Vision or Perspective, then leased scan classes/tag groups will do all the bookkeeping for you.
Leveraging the leased scan class is only an option if it is reasonable to expect the user will stay on that screen while the sequence in Clayton’s use case is “in control”. One of the benefits of an automated sequence is that it may free up an operator to be able to perform other tasks in parallel while the sequence is automating another activity / task. So in this instance, using leased scan classes could negate that benefit if the operator is expected to stay on that screen while the sequence is in control.
My opinion is that leased scan classes should only be leveraged for monitoring use cases and not where control related items may be reliant upon it. For me, I would say leased scan classes aren’t an option for Clayton since his use case is for control.
My takeaway from Clayton’s original post is the following.
-
The best scan class option for his use case (driven) will require him to create a larger number of scan classes than desired and longer term could be hard to manage.
-
system.tag.editTag, which may be the best known option for his use case, also comes with the drawback that the tags in question will get re-evaluated and may have unintended consequences. It also could get hard to manage longer term.
Are there any other options or could it be beneficial to consider the interaction between SFCs and scan class management further to see if there is value in an enhancement? Maybe a SFC leased scan class strategy where the lease is based on SFC activity (not displays)?
I agree with David’s last statement in particular here. I think the general concept of leased scan classes could potentially be very useful. Based on the documentation it looks like leased scan classes are based on component bindings. If SFC transitions/tasks were set up so that rather than entering tag paths, variables were defined then tags bound to those variables similar to component bindings, those bindings could be used as the basis for a leased scan class.
I could see having an opt-in means to lease groups happening on SFCs, or even directly exposing leasing to scripting, though that might be ‘dangerous’…
Would be a good ideas post for someone to make.