Dynacard Upload Driver Tag
Dynacard Upload Driver tags will read Dynacard information from a Pump Off Controller (POC). Create your Dynacard Upload Driver tags as children of one of these.
Dynacard data is read from the device using a series of Modbus commands rather than from a single address. For example, a “read” might consist of first writing to the controller, loading its registers with the data you’re looking for, and then sending several read messages to bring back a large block of data. The Dynacard Upload driver handles all of this sequencing and overhead, but uses the POC's Process Driver, a standard Modbus tag, to send and receive the actual messages.
The Dynacard data read from the device is logged by a linked Dynacard Input Tag that you create. These tags store all the card data in the historian (Min/Max Load, Stroke Length, etc.) but the only data shown onscreen are the position/load pairs that make up the Dynacard graph.
...POC-DV8 Tag
The ID tab of every tag includes the same common elements: Name, Area, Description, and Help ID.
Name:
Uniquely identifies each tag in the application. If the tag is a child of another, the parent names will be displayed in a separate area before the name field.
You may right-click on the tag's name to add or remove a conditional start expression.
Area
The area field is used to group similar tags together. By defining an area, you make it possible to:
- Filter for particular tag groups when searching in the tag browser
- Link dial-out alarm rosters to Alarm tags having a particular area
- Limit the number of tags loaded upon startup.
- Filter the alarm display to show only certain areas.
- Filter tag selection by area when building reports
When working with Parent-Child tag structures, the area property of all child tags will automatically match the configured area of a parent. Naturally, you can change any tag's area as required. In the case of a child tag, the field background will turn orange to indicate that you have applied an override.
To use the area field effectively, you might consider setting the same Area for each I/O driver and its related I/O tags to group all the tags representing the equipment processes installed at each I/O device. You might also consider naming the Area property for the physical location of the tag (i.e. a station or name of a landmark near the location of the I/O device). For serial port or Roster tags, you might configure the Area property according to the purpose of each tag, such as System or Communications.
You may define as many areas as you wish and you may leave the area blank for some tags (note that for Modem tags that are to be used with the Alarm Notification System, it is actually required that the area field be left blank).
To define a new area, type the name in the field. It will immediately be added. To use an existing area, use the drop-down list feature. Re-typing an existing area name is not recommended since a typo or misspelling will result in a second area being created.
There is no tool to remove an area name from VTScada since such a tool is unnecessary. An area definition will exist as long as any tag uses it and will stop existing when no tag uses it (following the next re-start).
Description
Tag names tend to be brief. The description field provides a way to give each tag a human-friendly note describing its purpose. While not mandatory, the description is highly recommended.
Tag descriptions are displayed in the tag browser, in the list of tags to be selected for a report and also on-screen when the operator holds the pointer over the tag’s widget. For installations that use the Alarm Notification System, the description will be spoken when identifying the tag that caused the alarm.
The description field will store up to 65,500 characters, but this will exceed the practical limits of what can be displayed on-screen.
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.
Dynacard Upload Driver properties Communications tab
I/O Device
Select that driver tag within the Pump Off Controller that will connect to the Dynacard data on the device.
Retries
The number of times to retry a message before declaring an error.
Use only if the driver is connected to a device that uses a serial port or a UDP/IP port that is configured to be polled. When connected directly to a device using TCP/IP, this value should normally be set to 0 since TCP/IP is a guaranteed message delivery protocol.
For unreliable communications, such as radio, set to 3 or 4.
Export
Specify a CSV format file, to which the Dynacard's read sequence data will be exported. This will allow you to view the sequence of Modbus reads and the addresses that will be used to read the Dynacard data. The sequence will be in the format that is used by the VTScada sequencer module (Sequencing Reads in a Pump-Off Controller)
The Dynacard Upload Driver tags that are automatically created as children of the various VTScada POC tags come preloaded with the proper sequence and in most cases you will not need to make any changes here.
Import
Specify a CSV format file that holds the Modbus read sequence that you want this Dynacard Upload Driver tag to use when reading the Dynacard data from the PLC. Usually the easiest way to edit the sequence is to export the existing sequence, make any necessary changes, save the file and then import that saved file.
Device Clock Time Zone
Select the time zone that the device uses in order to convert the time-stamped data from the device into UTC for storage in the VTScada historian. Regardless of the time zone selected with this option, the driver assumes that the device does NOT adjust its clock for daylight savings time (DST).
Defaults to the server's time zone, but may be set to use the device's clock if that is configured for UTC, otherwise any time zone where the device is located.
Observe Daylight Saving Time
Select if the RTU clock adjusts itself for Daylight Savings Time. Note that this does not necessarily mean that the RTU is in daylight savings time when this is being set. That is determined by the Windows operating system based on the selected time zone.
Read Number of X-Y Points from a Variable
In most cases, the number of X-Y pairs read from the POC are consistent (e.g. there might be 200 pairs of X-Y data that will then translate to 200 points on the Dynacard graph). Some devices can be configured to provide a different number of points each with each Dynacard. The number of points used is stored in a register that is read from the POC along with the rest of the Dynacard data. If that is the case, the Read Number of X-Y Points from a Variable parameter should be set.
The register in the POC that tells us how many points to read needs to be defined in the sequence CSV (which you can see by hitting the Export button). The register must be read and then assigned to the NumPoints variable using the GetValue_Numeric command (Sequencing Reads in a Pump-Off Controller)
Y Values are Read Before X Values
If not selected, X values are read first.
Use an Epoch Date of 01/01/2000 to Calculate Time Stamp
Select if this POC's time stamp format displays the number of seconds since the start of Jan. 1, 2000 (rather than the VTScada standard, which is the number of seconds since the start of Jan. 1, 1970).
Enable Tracing
If selected, a log file will be created under the Data\Trace folder of the application. This will be updated as each step of the Dynacard read sequence is completed. Traces can be useful when debugging problems with the sequence read, particularly if you have used the Export/Import buttons to change from the default sequence.
The following widgets are available to display information about your tags: