Transaction Logger Tags

Not counted towards your tag license limit.

Transaction Logger tags can be used to record a collection of historical values as a single transaction. These are useful for material-handling applications that must record transfers of custody.

When the trigger changes to a non-zero value, all of the records in the history associated with the I/O and Calculations, Analog Status, Digital Status, and String I/O tags that are immediate children of this tag, will be read and coalesced into a structure, which will be written as a single transaction record in the Historian associated with this tag. No other tag types will be included, nor will any tag that is below the level of the immediate children of the Transaction Logger. The TransactionLogger tag will not respond to a trigger event unless the child tags use the History Address field, not the address field

The field names in this transaction snapshot will match the names of the tags being recorded, and are generated in the order of I/O and Calculations, Analog Status, Digital Status and String I/O, with the fields being alphabetically ordered within types. All field names are stored with every transaction because the child tags of the Transaction Logger may change over time.

The driver parameter of all the child tags of a Transaction Logger must be set to that Transaction Logger. Child tags that do not use this tag for their driver parameter will not be included in the transaction.

Transaction Logger tags cannot share a common Driver tag with any other tags. You must create a dedicated Driver tag for each Transaction Logger tag.

You are advised to use the History address of the input tags where possible, so that there will be a positive confirmation of the data being read via WriteHistory. This will avoid false positives on communication errors due to other users of the driver having comm errors concurrently with the transaction's polling.

Avoid using Polling Drivers that are attached to the same driver and that have polling intervals that result in continuous polling. Doing so could result in transactions failing to complete.

Error Status

The value of the Transaction Logger tag shows its current error status, according to the following table:

Tag Value	Meaning
0	No error.
1	Communication Error.
2	For multiple-record devices (such as the ROC), the time stamps for consecutive records across all fields do not align.
3	Not all fields have the same number of records returned.
4	Driver became unavailable.

When there is an error, the I/O data corresponding to the poll attempt is written into the record, but these error records are not accessible via ODBC. In the case of the Communication Error, only one record will be written until the value becomes something other than 1. It is recommended practice to attach an alarm to each of your Transaction Logger tags.

Data Retrieval

There is a single, virtual ODBC table called TransactionLog, which presents the data for all transactions by all Transaction Logger tags. This table will be the merged columns that match the tags in the query. The table’s columns are defined by the child field tags that are present at the instant the query is made. There is a column, called TransactionLogger, that gives the associated Transaction Logger tag. Each record will have a 36-character GUID, stored in the column TransactionID.

The only method for retrieving logged transaction data is to use an SQL query. This may be done through code, calling the SQLQuery function, or through the ODBC Server. An example of an generic data retrieval query follows:

SELECT * FROM TransactionLog LIMIT 100;

Related information:

Best Practices for Tags

Transaction Logger properties ID tab

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 yellow to indicate that you have applied an override. (Orange in the case of user-defined types. Refer to Configuration Field Colors)

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.

Help Search Key

Used only by those who have created their own CHM-format context sensitive help files to accompany their application. Refer to Custom Help Files

Transaction Logger properties I/O tab

The I/O tab for the Transaction Logger tag consists of...

I/O Device

Select the communication driver tag from which data will be read.

By default, the tag will look for a parent tag that is a device driver (*Driver). If none is found, the text "--Missing--" will be displayed. The tag button to the right of the field opens the tag browser, from which you can either select an existing communication driver tag or add a new one. The X button will clear the field. Right-clicking on a tag in the field will open a dialog with which you can add or remove a Snapshot Expression or open a selected driver's properties dialog.

Trigger Condition

May be any tag or expression that will change from a zero to a one, signaling when to write the transaction record.

Acknowledge Output Destination

Must be a tag. In most cases, the PLC will need to know that the transaction has been read so that the PLC can update the registers for the next transaction that may be in the queue. The output provides that acknowledgment to the PLC.

Value to Write to Acknowledge

Provide the value that is to be written to the acknowledge output destination. This may depend upon the error status of the transaction tag, in which case an expression should be used to generate the appropriate value.

Force fields with different timestamps into separate transactions

When selected, data returned for each field does not have to have the same number of records. Time stamps that do not match will be placed in separate transaction records.

This option assumes that the time stamps are in order in tag history. The transactions will be written with the time stamps corresponding to the data times in chronological order. Should be selected for the TBox chronological data.