Tags and I/O
You are here...
At a glance:
For developers, this topic introduces the concept of tags for communication and configuration.
Find this in VTScada:
Click on the "Tag Browser" button on the Display Manager's title bar.
Related topics and things to know before reading this include:
Where to go from here:
Tags are the software representation of the parts of a physical system. A tag might represent the status of a pump, the level of a tank, a control switch to open a valve, etc. Tags also represent the connections to your hardware, both physical (TCP/IP or Serial) and software (the choice of driver). Further, tags are used to hold certain configuration settings including fonts, default colors for widgets, alarm priority characteristics and more.
In short, tags represent "things". Any things.
Points? A tag is a point and a point is a tag. VTScada uses the word "tag" more often (that's what the T in VTScada is for, after all) but "point" was used first, and you'll still see it from time to time.
The Tag Browser is the main tool for creating, modifying and deleting tags. It is also possible to export tags to a spreadsheet or database, then import changes back to the application. This is less user-friendly and is not advised for creating new tag hierarchies, but can save time when creating or updating many similar tags in existing hierarchies.
The Tag Browser allows you to organize your tags into a hierarchy so that it is easy to see which tags relate to which components in the system. Besides making it easier to find a given tag, this system makes it easy to expand the application by copying entire structures. A hierarchy also determines how some kinds of tags link to each other. Many tags work best when linked in such hierarchical structures. For example, I/O tags below the driver and dedicated alarm tags below the triggering tag.
While any tag could serve as the starting point to a hierarchy, the best choice is a Context tag, a container tag which provides a shared context to a group of related tags.
This note is relevant only to those with a multilingual user interface:
When editing any textual parameter (description, area, engineering units...) always work in the phrase editor. Any changes made directly to the textual parameter will result in a new phrase being created rather than the existing phrase being changed.
In a unilingual application this makes no difference, but in a multilingual application it is regarded as poor practice.
