Fisher ROC I/O Addressing
The Fisher ROC driver has an address assist module accessible from all standard I/O tags that are linked to a Fisher ROC driver. The address assist module is activated by clicking on the ROC button drawn on the I/O tab of all standard VTScada I/O tags.
Options within the Address Assist are revealed progressively, in response to your selections. Begin with Access Type as shown:
First step of the ROC Address Assist dialog.
Although the Address assist module exists to help users properly select complex Fisher ROC addressing, certain circumstances may dictate that addresses be entered manually. The following table lists the access types available to I/O tags connected to the Fisher ROC Communications driver:
| Access Type | Function |
|---|---|
| Point Access (*) | Used to read individual parameters. Reads are coalesced based on point type and logic number. |
| Parm Access (*) | Used to read individual parameters. Read coalescing is not ordered in any particular fashion. |
| Point History | Report by Exception. |
| Configurable Opcode Table | Used to read minute, daily, hourly, and statistical historical values form the device. |
| Alarm Log | Used to read the alarm log from the device. |
| Event Log | Used to read the event log from the device. |
(*) Refer to following descriptions and also to the section,
Point Access Address Format
Point access addresses are formatted as follows:
POINT:Type:Logical:Parameter
Where Type is the Point type, Logical is the logical number and parameter is the parameter number. As an example, to read AGA flow specific gravity for meter 1, the following address would be used:
POINT:7:0:5
Parm Access Address Format
Parm access addresses are formatted in the same manner as point access addresses.
PARM:Type:Logical:Parameter
Point History Address Format
The point history accessor is used to retrieve the following types of historical data:
- Minute
- Hourly
- Daily
- Statistical
Formatting will depend on your selection of the type of data and upon whether your device uses standard ROC addressing (in which case Ram Area must be selected) or ROC Plus (in which case the History Segment must be selected.) Examples are provided:
Standard ROC address for the daily history type, ram area 0 and history point 1:
POINTHIST:DAILY:0:1
Standard ROC address for the hourly history type, ram area 1 and history point 1.
POINTHIST:HOURLY:1:1
ROC Plus address for the minute history type, history segment #0 and history point 1.
POINTHIST:MINUTE:0:1
Statistical History addresses are formatted as follows:
POINTHIST:MINMAX:HistoryPointNumber:StatisticType
History point number specifies the history point number whose minute data is to be accessed. Statistic Type is used to specify the type of statistic to retrieve. The statistic values are as follows:
| Statistic Type Address Value | Statistic |
|---|---|
| 0 | Current Value |
| 1 | Minimum Contract Hour Value |
| 2 | Maximum Contract Hour Value |
| 3 | Minimum Value Yesterday |
| 4 | Maximum Value Yesterday |
| 5 | Last Hour Value |
Configurable Opcode Table Address Format
Configurable opcode table addresses are formatted as follows:
CNFOPTABLE:TableNumber:TableElement
TableNumber is used to specify the table number to access, and table element specifies the element number within the table to access.
Alarm Log Address Format
Alarm Log addresses are formatted as follows:
ALARMLOG:AlarmFieldNum
Where AlarmFieldNum specifies the alarm record field as shown in the following table:
| Alarm Address Field Number | Statistic |
|---|---|
| 0 | Alarm Type |
| 1 | Alarm Code |
| 2 | Alarm tag |
| 3 | Alarm Value |
Event Log Address Format
Event Log addresses are formatted as follows:
EVENTLOG:EventFieldNum
Where EventFieldNum specifies the alarm record field as indicated in the following table:
| Event Address Field Number |
Statistic |
|---|---|
| 0 | Point Type |
| 1 | Parameter Number |
| 2 | Timestamp |
| 3 | Point Number |
| 4 | Operator ID |
| 5 | Old Value |
| 6 | New Value |
| 7 | FST Number |
| 8 | Event Text |
| 9 | Event Value |
| 10 | Event Timestamp |
| 11 | Calibration Type |
| 12 | Calibration Info 1 |
| 13 | Calibration Info 2 |
ROC Address Storage
ROC addresses are stored as a series of CSV files, stored in the C:\VTScada\VTS folder. You may view these files for reference, but you cannot edit them because they are a part of the VTScada layer. The files are:
- ROCDeviceTypes.CSV – a list of all of the various ROC devices supported by VTScada and their accompanying TypeID. This TypeID will be important if you are configuring custom addresses.
- ROCPointTypes.CSV – all list of all of the possible point types (the "T" from the address’ "TLP"). The description on the left is used in the ROC address assist, but only the PointType number matters when configuring custom addresses.
- ROCPointDefinitions.CSV – a list of every address that can be read from every ROC device type.
You can add custom ROC point definitions by selecting your own CSV file that contains those definitions. The file may be stored anywhere on your computer but when imported, a copy of that file will be added to the application and placed in C:\VTScada\YourAppName\CustomROCPoints\. If you want to edit the file after it has been imported, you’ll need either to directly edit the copy in CustomROCPoints or you’ll need to edit your original file and then re-import it from the ROC tag’s configuration folder.
The contents of this file are appended to the standard ROCPointDefinitions.CSV file, which is still read. If a parameter is defined in both the new file and the standard one, the new definition is used for that parameter.
The new CSV file must have the same format as the standard ROCPointDefinitions.CSV and therefore must contain the following fields:
- Device Type – the TypeID as referenced in the ROCDeviceTypes.CSV file, this defines the ROC Device Type that will use this definition (e.g. FloBoss 107, ROC800, etc.). If you want your new definition to be used by more than one device type then you will need to include it multiple times, each with a different number in the Device Type field.
- Point Type – The PointType, as referenced in the ROCPointTypes.CSV file. This will define the T in the TLP. Most often, users who are editing this file will be redefining all of the parameters for a given point type.
- Parameter Number – The P in the TLP, this is where you specify which individual parameter you are defining. Note that while these parameters do not need to be listed in any particular order, you shouldn’t leave any "holes" in your block of parameters. In other words, if you want to read parameter 7 and parameter 10 you should also include definitions for parameters 8 and 9.
- Bit Number – Only applicable to binary (or BIN) types, this is the bit number within the overall byte that you are defining. Look at 7:0:14 in the standard file for an example.
- Data Type – Tells the ROC driver how to interpret the data coming from the RTU. Options include:
- BIN – a binary word
- INTx – a signed integer, where x is the number of bits in the response (8, 16, 32)
- UINTx – an unsigned integer, where x is the number of bits in the response (8, 16, 32)
- FL – 4-byte floating point
- DBL – 8-byte double floating point
- TLP – a 3-byte TLP address
- AC – ASCII text
- TIME – 4-byte timestamp
- Data Length – The number of bytes expected in the response. This is closely tied to the data type, but may vary for some types like AC.
- Access – either "R/W" (can read or write) or "R/O" (can only read, writes are disabled)
It is not necessary to restart the application after loading a custom point definition file, but this file is not monitored for changes while the application runs. If you edit the file, you must restart the application before the changed point definition will be used.
Efficient Data Collection
When accessing current parameter values, various strategies can be used to increase communications efficiency based on the TLP distribution of the I/O tags being accessed. the following three accessor types will be further explained in order for users to properly select the accessor strategy to meet the particular Tag address distribution of the application.
Point Access
Will coalesce reads based on a combination of Point type and logical number. This accessor method should be used when the values of many tags, or groups of tags, being accessed have a TLP with identical point type and logical number. As an example, when accessing the following set of TLPs using the Point Access accessor:
(5:0:1, 5:0:2, 5:0:5, 5:0:6, 5:0:7, 5:0:8, 5:0:9, 5:0:10, 5:0:11, 5:0:12, 5:0:13, 5:0:14, 5:0:15, 5:1:5, 5:1:6, 5:1:7, 5:1:8, 5:1:11, 6:0:4, 6:0:5, 6:0:6, 6:0:7)
The parameters will be accessed using three separate reads.
- Begin at 5:0:1 for 15 parameters
- Begin at 5:1:5 for 7 parameters
- Begin at 6:0:4 for 4 parameters
Parm Access
Will coalesce as many reads into a single message as possible. The number of parameters that can be coalesced into a single message is limited by the maximum ROC protocol message size. Given the example above:
(5:0:1, 5:0:2, 5:0:5, 5:0:6, 5:0:7, 5:0:8, 5:0:9, 5:0:10, 5:0:11, 5:0:12, 5:0:13, 5:0:14, 5:0:15, 5:1:5, 5:1:6, 5:1:7, 5:1:8, 5:1:11, 6:0:4, 6:0:5, 6:0:6, 6:0:7)
The driver will coalesce the reads into a single request. the efficiency of this accessor is lost in the fact that the TLP of each parameter being accessed must be included in the request, thus require more bandwidth in the request than simply specifying the starting TLP and the number of parameters to read. This accessor is efficient when accessing parameters which do not share common Types and logical numbers, and when the configurable opcode table has not been implemented in the device.
Configurable Opcode Table
This can be useful when the feature has been implemented in the device configuration. ROC devices allow often accessed TLPs to be assigned to particular indexes with the configurable opcode table. All values within the table can be accessed using a single read. The protocol specifies the starting index and the number of values to retrieve.
Historical Data Retrieval
Status of historical data, including alarms, events, and process data collected from the HMI is not maintained within the ROC devices. This means that the ROC device does not keep track of which data has been retrieved, and will readily allow the HMI to access all logged data within the device. To prevent duplicate readings within VTScada, the driver will retain the timestamp of the last data record, for each data type, and only retrieve records whose timestamps are newer than the previously retrieved record. On the initial connection to a device, the driver will have no retained timestamp and retrieve all available data.
