(VTScada-Layer function. Must be called with a leading backslash.)
| Description: | Wrapper for TagMigrator\OpChange. Performs an immediate deploy of a single tag change without disturbing any other tag changes already in place on the local branch. The tags must already exist. |
| Returns: | Object value of the worker module. |
Usage:  |
Script Only. |
| Function Groups: | Configuration |
| Related to: | SimpleOpChange | ModifyTags |
| Format: |
\OpChange(TagName, ParmsDict, User[, Comment, Merge]) |
| Parameters: |
| Tagname |
| Required. The name of the tag to be changed. |
| ParmsDict |
|
Required. A dictionary of tag parameters to change. {
"Address": 40001,
"Questionable": 0
}
|
| User |
| Required. The user responsible for the operational change. |
| Comment |
| Optional text. A descriptive comment about the change. |
| Merge |
| Optional Boolean. Defaults to TRUE. Controls whether the parameters are to be merged with the existing tag's parameters. If false, the parameters replace the tag's parameters and are expected to contain user and timestamp metadata. |
| Comments: | If your application is set to auto-deploy, then OpChange and ModifyTags accomplish the same result. If auto-deploy is not set, then there is a difference in the result of the two functions. ModifyTags makes a tag change locally, whereas OpChange will immediately deploy that tag change. Running a deploy operation after ModifyTags' change, results in the entire tag file (and all the included tags and their parameters) being deployed. OpChange is able to deploy just the one change to the one tag within the file, leaving other modified tags in that file as local changes. OpChanges are used for any tag change that is expected to be performed during systems operation, as opposed to changes made during configuration. The example is an operator changing a tag's questionable status by using the context menu rather than opening the configuration dialog. |
