ABB Totalflow Driver
Use the ABB Totalflow driver tag to communicate with a variety of Totalflow devices produced by ABB. This VTScada driver relies upon a COM server developed by VTScada and that constitutes a wrapper around ABB's TCI-3.13 library. (Note that the TCI library is copyrighted by ABB).
The driver requests transactions such as DB2FCU Read Device Setup transaction or Read Registers transaction from the COM server. This server is responsible for handling the TCP communication with the ABB Flow Computer device to perform the transaction and then hand out the results of the transaction to the driver. The driver instantiates the COM Server and requests operations and data using its interfaces.
The COM server ships with and is installed by VTScada. No configuration is required. It is launched automatically when needed and terminated by the driver.
When being used by the driver, the COM server will show in Windows Task Manager, Details view as "ABBTCIWrapper.exe".
Troubleshooting:
-
To verify that ABBTCIWrapper installed correctly, a search of your Windows Registry for ABBTCIWrapper should find it in multiple places such as that shown in the following figure:
-
VTScada will install ABBTCIWrapper.exe using 32 or 64 bits architecture to match your VTScada installation. (32-bit or 64-bit) If you decide to switch from one architecture to the other you must uninstall VTScada first (to also remove ABBTCIWrapper) and then install the new version.
-
The driver will spawn a single instance of the COM server for a single transaction with an ABB Totalflow device at a time. If you have multiple driver instances running in your app you might see multiple instances of ABBTCIWrapper.exe in the Task Manager.
Each instance of the COM server will close after a transaction is finished and the results are returned to the driver.
All instances of the COM server should close if the VTScada application stops. If the shutdown is not graceful, then some instances of ABBTCIWrapper.exe may linger in memory. These do not affect new wrapper instances but waste memory and will prevent a new installation of the COM server. Restarting the server is an effective way to clear the instances or you can stop each instance using the Task Manager. Advanced users can use the command "taskkill /F /IM ABBTCIWrapper.exe" in an elevated command prompt to stop all of the instances.
Communication Methods Supported
Totalflow RTUs are capable of different modes of communication with SCADA host systems using variants of protocol messaging. Early Totalflow RTUs, manufactured in the 1980s and 1990s, use the DB1 FCU protocol. Newer Totalflow RTUs, beginning with late model Totalflow G3 models, use the DB2 FCU, DB2 Register, and DB2 Trend protocols.
Communication protocols currently supported by the VTScada Totalflow Driver include:
Method | Comments |
---|---|
DB1 FCU | Not supported. |
DB1 FCU + VCI | Not supported. |
DB2 FCU | Supported |
DB2 Register | Supported |
DB2 Trend | Supported |
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.
Server List
Select (or create) a named server list.
ABB Totalflow Driver properties: Device Info tab
Port
It is the COM server that performs all the communication. The TCP Port tag specified here is a place holder used for backward compatibility. It will specify the remote ABB Totalflow device's address / port and that information is passed by the driver to the COM server
The driver supports only TCP/IP port tags.
Station ID
The station ID of the device. (Before multimeter devices were created, this was referred to as the meter Id.) The station ID is 1 to 10 printable characters.
Security Code
The four-character security code assigned to the device. Allowable characters are ASCII hex 30 through hex 39 (decimal characters 0 through 9).
Maximum Read Block Size
The block size that should be used when filling packets. The block is the smallest subset of a message that is CRC protected, so the block is the smallest subset that can be requested in a retry.
Packet Size
The number of bytes that are contained in a single message from the device to the host. In the DB2 protocol, the host returns an ACK for each message (packet plus header) that is received, so the larger the packet size, the fewer number of device transmissions and host acknowledgments are required.
Device Clock Time Zone
Defaults to the server's time zone.
ABB Totalflow Driver properties: Communications tab
Timeout Limit
The time the driver will wait for a response before setting an error or retrying.
Retries
The number of times to retry a message before declaring an error.
Hold
Select this to have I/O tags attached to the driver hold their last value in the event of a communication failure. If not selected, tags will have their value set to invalid on a communication failure.
Link Time
Time, in seconds, to send request frames.
Debug Level
The debugging level for communication between the driver and the ABBTCI COM server. Debug output can be found in the application’s "\Data\TraceFiles\ABBTFLogs" directory.
Debugging information is saved to files named "s_Sanitized name of the driver tag-YYYY-MM-DD.LOG" for example "s_Westwells-ABBTFD2-2023-11-08.log
The ABBTCIWrapper.exe COM server logs debugging information to files named "Sanitized name of the driver tag_Tube(TubeNbr)_YYYY-MM-DD.LOG" for example:"Westwells-ABBTFD2-Tube(0)-2023-11-08.log"
YYYY-MM-DD represents the date on which the data was recorded to the file.
The application property, TotalflowAutoDebugDisableTime, specifies the length of time that logging stays in INFORMATION or VERBOSE mode before it is automatically switched to ERROR.
ABB Totalflow Driver properties: Request tab
Operator ID
Required if the device is configured to record the name of the operator with each event or to use role-based access. Leave blank otherwise.
Password
If the device is configured to use role-based access, values for both Operator ID and Password are required. Leave blank otherwise.
Compress Response
A flag that indicates if the data content in the response should be compressed. This is not available with DB2 Register requests.
Flow Header
Determines if the flow header (ranging in size from 200 to 500 bytes) should be retrieved in a historical collection.
If selected, the device returns the flow header at the start of the response so that flow header fields are used for decoding the other records in the response.
If not selected, the device returns an 8-byte header before each record type in the response.
Daily Records
Select if the Daily Records should be retrieved as part of the historical collection.
Log Period Records
Select if the Log Period records should be retrieved as part of the historical collection.
Event Records
Select if the original Event records should be retrieved as part of the historical collection. This setting is mutually exclusive of New Event Records.
Alarm Log
Select if the Alarm Log records should be retrieved as part of the historical collection.
New Event Records
Select if the new Event records should be retrieved as part of the historical collection. This setting is mutually exclusive of Event Records.
Collecting Events
Select if the device should treat this transaction as a collection process. Devices configured to operate in conformance with Canadian measurement requirements retain all events until collection is complete. Setting this flag causes the device to mark the retrieved events as reusable so that the events are overwritten, when necessary.
History Collect Method
Determines how the historical collection is retrieved. May be one of:
0 – by recent days
1 – by start and stop sequence number
2 – by start and stop time
Maximum Days
Limits the number of days of history to collect.
ABB Totalflow Driver properties: Trend tab
Trend Collect Method
Determines how a Trend file is retrieved. May be one of:
0 – Days
1 – By start and stop sequence number
2 – By start and stop timestamp
Trend Directory
Sets the base folder holding the Trend file. Added to the FILE portion of the Trend datum address:
(TR:FILE:ATTRIBUTE
The following widgets are available to display information about your tags:
ABB Totalflow Communication Messages Dialog
This Communication Messages Dialog will be drawn for the driver but will not show any data because all communications are done by the COM server, which follows a closed, proprietary protocol