Location of output Report files to be generated.

Default option is "RAM Drive" (/tmp/director).

Configurable text field, which may be included in an MQTT topic for a Report using the ${GROUP} wildcard variable (see Report Name property of the Process-RTDB-Report or Process-FILE-Report objects).

Group ID serves a similar function as the MQ-RBE "Console ID" or Sparkplug "Group Name" properties, to allow an MQTT topic level grouping of RediGate sites.

Spare property.

Field Unit address used for process logic and obtaining RTDB data.

For the Generic-Registers process, the options include:

• Generic Data Block – generic process for creating Report out of RTDB or file data.
• DISABLE THIS ROW – use this to temporarily disable one or more process rows.

RTDB register address containing the first of 5 Field Unit communication status registers (register should contain 7=good, 0=bad comms). If the communication status is checked and found to be in a failed state, the processing on this row will be skipped.

Following the convention of the Field Unit's Comm Status Holdreg, use a 40,xxx register to point to the communication status register in the System Status RTU, or use a 30,xxx register to point to the communication status register in the Field Unit's own RTDB.

Set CommStatReg to 0 to check protocol status of the Master Channel's protocol driver instead of a Comm Status Holdreg register.

Set CommStatReg to -1 to ignore the communication status. Process logic for this row will occur regardless of comms status.

If this row uses a Process-RTDB-Report or Process-PBuf-Report type:

If DataRegs is non-zero, that RTDB register in Channel/RTU is used as the "base register" for Report generation. The Report defines offsets from DataRegs.

This option may be used when more than one block of similar data is stored in the RTDB; thus, the same Report can be reused by setting DataRegs to the starting register of each block of registers. (For example: Field Units 1 and 2 each have analogous blocks of data at 40001-40020 and 40101-40120. Four rows could be defined in Generic Registers with different RTU address (1 and 2) and DataRegs column (starting address 40001 and 40101), and Report defined with data elements at Offset 0 through 19; the same Report would be called four different times using data from different units and different blocks of data).

If DataRegs is zero, the Report must be defined using actual register addresses in the RTDB.

This option might be used, for example, if a set of numbered addresses with similar data is used in multiple Channel/RTU/RTDB. The registers do not have to be in a contiguous block of addresses. (For example: Field Units 1 through 10 each have an analogous data at 10001-5 and 40001-40020. Ten rows could be defined in Generic Registers with different RTU addresses, DataRegs set to 0, and the Report defined with data elements at fixed register locations 10001-10005 and 40001-40020; the same Report would be called ten different times using data from different units).

If this row uses a Process-FILE-Report type:

DataRegs should be the RTDB register of a STRING type value, where the Tag Name of the register must be defined as the name of the text file containing data to process. The directory "/tmp/director/" is added to the beginning of the Tag Name, plus a suffix "_CC_RRRRR" is automatically appended to the Tag Name (where CC is the Channel and RRRRR is RTU/Field Unit address configured on this row, each with leading zeros as needed). The contents of the specified DataRegs RTDB register is unused.

For instance, assume there is a text file containing ASCII data, stored with the filename of  /tmp/director/MyData_01_0005. For this row, configure Channel=1 and RTU=5. If DataRegs is configured as 48001, then the Channel 1, unit 5, Tag Names object should have register 48001 defined with a Tag Name of "MyData". The above filename will be opened and used to generate the output Report.

The TrigMode option selects a method for triggering the Report generation. See below for more information on the TrigMode options.

For instance, the Report generation logic could be triggered based on timing (day, minute, or hour), on a register value matching a certain condition, or any change in the value of any register in a block of registers.

If a Report generation logic is "triggered," the trigger value in the TrigReg can be modified based on the TrigAdjust option (e.g., to prevent the Report from being immediately triggered again). TrigAdjust options are:

• None - no modification to TrigReg after Report generation.
• REMOTE INCREMENT - Increment the trigger value and write it to remote Channel/RTU/TrigReg register. Set TrigWrap and Parm1 to handle roll-over.
• REMOTE DECREMENT - Decrement the trigger value and write it to remote Channel/RTU/TrigReg register. Once the value decrements to zero, it will not be decremented further.
• REMOTE ZERO - Set the trigger value to zero and write it to remote Channel/RTU/TrigReg register.
• RTDB INCREMENT - Increment the trigger value and set the Channel/RTU/TrigReg RTDB register. Set TrigWrap and Parm1 to handle roll-over.
• RTDB DECREMENT - Decrement the trigger value and set the Channel/RTU/TrigReg RTDB register. Once the value decrements to zero, it will not be decremented further.
• RTDB ZERO - Set the trigger value to zero and set the Channel/RTU/TrigReg RTDB register.

If the TrigAdjust "INCREMENT" option is used, TrigWrap tells at what point the value should roll over to its low ("WrapTo") value. If TrigWrap is greater than 20000, it is used as a register point to a maximum "Increment" value. If less than 20001, it is a constant value.

For instance, if TrigWrap is set to 40001, and the value in 40001 is 30000, then if the TrigReg register will be incremented to 30000, then after the next Report trigger, it will be set to the value in Parm1.

If the TrigAdjust "INCREMENT" option is used, Parm1 contains the "WrapTo" value. Once the value rolls over at its maximum limit, it will be set to the constant integer contained in Parm1.

For instance, this may be used to set the minimum roll-over value to 1 instead of 0, if a particular trigger value requires it.

(This is the "Parm2" parameter.)

If the TrigMode "CRC" option is used, this value determines the number of sequential registers starting at DataRegs that will be calculated for the CRC, to determine if any of the registers has changed. See below for a discussion on the TrigMode options.

Field Unit address useof the Omni or Allen Bradley device.

For the Time-Syncs process, the options include:

• Omni Time Sync – special logic for sending time to Omni flow computer 
• DF1 Time Sync – special logic for sending time to Allen Bradley PLC
• Ignore This Row – use this to temporarily disable one or more process rows.

RTDB register address containing the first of 5 Field Unit communication status registers (register should contain 7=good, 0=bad comms). If the communication status is checked and found to be in a failed state, the processing on this row will be skipped.

Following the convention of the Field Unit's Comm Status Holdreg, use a 40,xxx register to point to the communication status register in the System Status RTU, or use a 30,xxx register to point to the communication status register in the Field Unit's own RTDB.

Set CommStatReg to 0 to check protocol status of the Master Channel's protocol driver instead of a Comm Status Holdreg register.

Set CommStatReg to -1 to ignore the communication status. Process logic for this row will occur regardless of comms status.

Starting register in the RTDB for the device timestamp registers polled from the Omni or Allen Bradley device. In the Allen Bradley, some custom programming is required to place the timestamp into six consecutive registers (Year, Month, Day, Hour, Minute, Second), and a seventh register is written to by the RediGate, which the PLC must take the new timestamp and store into the PLC's clock. For the Omni, the RediGate will read the standard six timestamp registers (Omni registers 3867-3872: Hour, Minute, Second, Month, Day, Year).

Unused

RTDB address in Channel/RTU containing a trigger to synchronize the time whenever the TrigReg register is non-zero. This can be used, for instance, to read the "Power Fail" flag (Omni register 1829).

(This is the "Run" parameter.)

Optional parameter, can be used to automatically write the timestamp to the device once/day at a certain Hour and Minute.

(This is the "Parm1" parameter.)

Optional parameter, can be used to automatically write the timestamp to the device once/day at a certain Hour and Minute.

Field Unit address used for the PLC.

For the Heart-Beat-Monitor process, the options include:

• Heartbeat Monitor – special logic for PLC heartbeat monitoring and MQTT death certificates
• Ignore This Row – use this to temporarily disable one or more process rows.

RTDB register address containing the first of 5 Field Unit communication status registers (register should contain 7=good, 0=bad comms). If the communication status is checked and found to be in a failed state, the processing on this row will be skipped.

Following the convention of the Field Unit's Comm Status Holdreg, use a 40,xxx register to point to the communication status register in the System Status RTU, or use a 30,xxx register to point to the communication status register in the Field Unit's own RTDB.

Set CommStatReg to 0 to check protocol status of the Master Channel's protocol driver instead of a Comm Status Holdreg register.

Set CommStatReg to -1 to ignore the communication status. Process logic for this row will occur regardless of comms status.

Unused

Unused

Unused

Unused

Field Unit address of the Omni Modbus unit used for process logic and obtaining RTDB data.

For the Omni-Modbus-Archives process, the options include:

• OMNI Modbus Archive – logic to retrieve and publish batch/ticket archives for an Omni Modbus flow computer.
• Spirit Modbus Archive – logic for Spirit flow computer (same as Omni Modbus logic?)
• Ignore This Row – use this to temporarily disable one or more process rows.

RTDB register address containing the first of 5 Field Unit communication status registers (register should contain 7=good, 0=bad comms). If the communication status is checked and found to be in a failed state, the processing on this row will be skipped.

Following the convention of the Field Unit's Comm Status Holdreg, use a 40,xxx register to point to the communication status register in the System Status RTU, or use a 30,xxx register to point to the communication status register in the Field Unit's own RTDB.

Set CommStatReg to 0 to check protocol status of the Master Channel's protocol driver instead of a Comm Status Holdreg register.

Set CommStatReg to -1 to ignore the communication status. Process logic for this row will occur regardless of comms status.

If DataRegs is non-zero, that RTDB register in Channel/RTU is used as the "base register" for Report generation. The Report defines offsets from DataRegs. For the Omni-Modbus-Archives process, this will generally be the block of data containing the latest archive record.

This option may be used when more than one block of similar data is stored in the RTDB; thus, the same Report can be reused by setting DataRegs to the starting register of each block of registers. (e.g., Field Units 1 and 2 each have an analogous block of data at 40001-40020 and 40101-40120. If more than one archive is obtained, multiple rows can be defined in this table for the same RTU address, and rows for each Modbus flow computer, with each row calling one or more Report definitions.

If DataRegs is zero, the Report must be defined using actual register addresses in the RTDB.

Unused

Unused

(This is the "Parm1" parameter.)

This must be set to the RTDB register used in the SOS table that enables and disables the poll for the actual archive data record. The processing logic will set this register to True (or 1) to enable the archive poll, and set it to False (or 0) once the record has been received.

Field Unit address of the Omni Modbus unit used for process logic and obtaining CMD 65 file data.

For the Generic Registers process, the options include:

• OMNI-7K Batch ASCII Archive – logic to retrieve and publish batch/ticket archive for Omni 7000 using Cmd65.
• OMNI-7K Snapshot ASCII Archive – logic for to retrieve and publish Snapshot archive for Omni 7000 using Cmd65.
• OMNI-6K Batch ASCII Archive – logic to retrieve and publish batch/ticket archive for Omni 6000 using Cmd65.
• OMNI-7K ALARM – logic to retrieve and publish Alarm archive for Omni 7000 using Cmd65.
• OMNI-7K AUDIT MEASUREMENT – logic to retrieve and publish Measurement Audit archive for Omni 7000 using Cmd65.
• OMNI-7K AUDIT SYSTEM – logic to retrieve and publish System Audit archive for Omni 7000 using Cmd65.
• Ignore This Row – use this to temporarily disable one or more process rows.

RTDB register address containing the first of 5 Field Unit communication status registers (register should contain 7=good, 0=bad comms). If the communication status is checked and found to be in a failed state, the processing on this row will be skipped.

Following the convention of the Field Unit's Comm Status Holdreg, use a 40,xxx register to point to the communication status register in the System Status RTU, or use a 30,xxx register to point to the communication status register in the Field Unit's own RTDB.

Set CommStatReg to 0 to check protocol status of the Master Channel's protocol driver instead of a Comm Status Holdreg register.

Set CommStatReg to -1 to ignore the communication status. Process logic for this row will occur regardless of comms status.

(This is the "DataRegs" parameter.)

The FileNameReg should typically be a STRING type register in the RTDB, which is used by the Poll Table to specify the name of the file created by the Modbus CMD 65 data acquisition of the raw ASCII report. The Tag Name of this register identifies the filename; the retrieved file to be processed will be stored in /tmp/director/ with a filename of TagName_CC_RRRRR, where "TagName is the tag of the FileNameReg, "CC" is the Master Channel number and RRRRR is the Modbus unit ID (the Omni CMD 65 poll automatically appends these numbers with the underscores).

Unused

RTDB address in Channel/RTU containing data to trigger when the raw ASCII text file has been acquired and is ready to be processed.

• For Omni 7K (Batch, Prover): TrigReg must point to the 1st of 9 registers in the RTDB used by Cmd65 data acquisition (1st register=Request ID, 8th register=Number of records, 9th register=Newest record ID).
• Omni 7K Snapshot: TrigReg indicates when new Snapshot ASCII file has been acquired (for instance, the first 128 bytes of Snapshot report could be polled, containing header lines of ASCII file, and use Timestamp option to update 32-bit timestamp when the header data changes → use the Timestamp for TrigReg).
• For Omni 6K: TrigReg is a register that changes when a new ASCII report is available (for instance, could be a Timestamp register generated based on data changing in the poll for ASCII data from Omni).

Unused

(This is the "TrigWrap" parameter.)

• Omni 7K – RTDB register containing feedback of requesting ASCII file report ID, to indicate when the report is ready. Register will contain 0=Report ready, 1=Pending (in process), 2=Error.
• Omni 6K – Unused

(This is the "Run" parameter.)

RTDB register for writing the "Count HistRecords" parameter, below, used to request a count of historical archives for certain types of Cmd65 reports (Alarm, Audit).

Otherwise, the HistRecord parameter is unused, other than optional use in an MQTT topic using the "${RUN}" variable.

(This is the "Parm1" parameter.)

This must be set to the RTDB register used in the SOS table that enables and disables the poll for the actual archive data record. The processing logic will set this register to True (or 1) to enable the archive poll, and set it to False (or 0) once the record has been received.

(This is the "Parm2" parameter.)

This is the count of historical records needed in the request for certain types of historical archives. This is the value written into HistRecord, above.

Parse and publish archive data report for file named in Tag of register 60001.

The Report Name is used for a dual purpose. It defines a file to be created in the filesystem into which the contents of the Report data is saved. All report files are saved to the Report Directory location defined in the Processes object (such as /tmp/director/Reports or /tmp/sdcard1/Reports).

The name of the report is also used as the MQTT topic name when publishing the report via one of the MQTT processes. Any single tilde (~) in the Report Name will be converted to a slash (/) in the MQTT topic name. 

If the Report Name begins with "${TIME}~~", the filename up to the double tildes will be removed before converting the filename to an MQTT topic.

The Report Name may use wildcard variables, which will be substituted when the Report is created. See Automated Processing#Report Name Wildcards. below.

Example:
A Report Name "${TIME}~~DAT~${GATE}~${CHAN##}~${RTU##}" on a RediGate named "Site1", called by a Process row using Channel 1, RTU 5, might create a filename of "20190703T150233.Z000~~DAT~Site1~01~05". This would be published by MQTT with a topic of "DAT/Site1/01/05".

When a ProcessScript publish action is selected, the Report Name is passed to the Bash script as the first command line parameter, which may be used by the Bash script to identify the name of the Report to be acted on.

The Output Mode defines the structure of data to be saved into the Report. The report may be a Binary structure or a text format (CSV, JSON, XML, TXT, etc.). 

See Automated Processing#Report Output Modes, below, for a description of the different Report types.

Select the action to take once the Report has been created. MQTT processes will publish the Report file, using the filename as the topic. ProcessScript options will run a script after creating the Report, with the script located in /usr/director/bin/ProcessScript0.blnk (or similar). To create these scripts, use the Proc-Script-Text or Bash Script object – the script must be named "ProcessScript0" (ending with a digit 0 through 9).

Options are:

• MQtt Client (publish using the MQTT Client object with no instance number)
• MQtt-Extra Client 0 (MQTT Extra Client with instance 0)
• MQtt-Extra Client 1 (MQTT Extra Client with instance 1)
• HttpPost Client (not currently supported)
• Not publishing (don't do anything with the Report file, just create it)
• ProcessScript0 (through ProcessScript9) – run a Bash script with this name.

For most Report types, the Report Header field is not used.

For XML reports, the Report Header is used as the first line of the XML file between "<?   ?>" tags.

When using the ProcessScript publisher process, the Report Name is passed to the Bash script as the first command line parameter, followed by the Report Header as one or more additional command line parameters. This may be used to pass some defined variables or other parameters into the script.

Number of Report files of a particular name, channel, and RTU to retain in the filesystem.

This option is only currently used when the Report Name begins with "${TIME}" (variable filename), in order to limit the number of retained archive files. All of the other Report Name Wildcard options result in a fixed Report Name, which is overwritten each time.

See the sections below for definition of different types of Report tables.

Process-RTDB-Report
Process-FILE-Report object
Process-PBuf-Report object

Insert the current time and date into the Report filename when it is created. Time is created in the form: YYYYMMddTHHmmss.Z000 (such as "20190703T150233.Z000").

This will result in multiple Report files, with the quantity of stored files limited to the Number of Archives. Typically, the ${TIME} should be followed by two tildes (~~), so that when the file is published, the filename will be converted to an MQTT topic that excludes the time and date and the two tildes.

Unit Name property of the gateway, taken from the System object.

${GATE#}
${GATE#####}

Unit Address property of the gateway, taken from the System object, such as "241"
(with leading zeros when more than one "#" is used, such as "00241").

${PARM1#}
${PARM2#}

Value from the Parm1 or Parm2 column in the Process row that called this report (with leading zeros, if more than one "#").
Note that in some Process types, the column names are different. Parm1 is always column 13, Parm2 is column 14.

Store data into a binary (hex) data format, byte for byte, using the Output Format of each row in the Report Definition Table to determine the number of bytes used for each element.

Nesting and Array structures and Label elements in the Report are not supported. The Report Header property and Units column are unused.

XML (Attributes Only)

XML (Values and Attributes)

Store data as XML format, where every row in the report adds a sequential XML parameter with a "<field>" element name. The Report Header property creates a starting XML tag inside "<?    ?>" characters. Variable name and any defined Units are stored as attributes of the <field> element.

"XML (as Attributes Only)" stores the value with a "Value=" attribute inside the XML tag.

"XML (Values and Attributes)" stores the value in between the <field> </field> tags.

Nesting creates an XML section with the element name ("<name>  </name>") from the Name column in the NESTING START row of the Report. (The NESTING END must use the same Name column value as its matching NESTING START row.)

Arrays create an XML "<array>  </array>" element.

In the two examples below, the Report Definition includes several data fields, an array called "1st Array", and a Nesting section called "1stObject".

Example (Attributes Only):

<?xml version="1.0" encoding="UTF-8"?>
<REPORT Name="ReportName">
  <field Name="40001", Units="degF", Value="9999" />
  <array Name="1stArray">
    <field Name="40002", Units="degC", Value="9999" />
    <1stObject>
      <field Name="MyFloat", Units="psi", Value="3.141500" />
      <field Name="MyString", Value="This is a String32 register" />
    </1stObject>
  </array>
  <field Name="Calc-CRC-32", Value="0x0" />
</REPORT>

Example (Values and Attributes):

<?xml version="1.0" encoding="UTF-8"?>
<REPORT Name="ReportName">
  <field Name="40001", Units="degF">9999</field>
  <array Name="1stArray">
    <field Name="40002", Units="degC">9999</field>
    <1stObject>
      <field Name="MyFloat", Units="psi">3.141500</field>
      <field Name="MyString">This is a String32 register</field>
    </1stObject>
  </array>
  <field Name="Calc-CRC-32", Units="none">0x0</field>
</REPORT>

Store data as JSON format, where every row in the report adds a tag/value pair in the JSON structure.

Nesting creates a JSON object "Name:{ }", where the Name comes from the Name column in NESTING START row of the Report.

Arrays create a JSON array "Name:[ ]" structure, where the Name comes from the Name column in the ARRAY START row of the Report. Elements between ARRAY START and ARRAY END are comma-separated and do not include the tag name, only the value (or nested { } object).

Label elements are not supported.  The Report Header property and Units column are unused.

In the examples below, the Report Definition includes several data fields, an array called "1st Array", and a Nesting section called "1stObject". In the JSON output, the tags "gwName" and "devName" are added automatically with the RediGate Unit Name and the Channel/RTU Unit Name, the same as used in JSON-RBE messages.

{
  "gwName":"UnitName",
  "devName":"RTUName",
  "40001": 9999,
  "1stArray":
    [
      "40002":9999,
      "1stObject":
        {
          "MyFloat": 3.1415,
          "MyString": "This is a String32 register"
        }
    ]
  "Calc-CRC-32": 0x0
}

Store data in CSV format, with every row in the Report as a comma-separated column. First row of file is the column headers taken from the Name column of each data element in the Report (or a register number, if the Name/Tag isn't defined). Second row contains the data value for each element.

Nesting and Array structures and Label elements in the Report are not supported. The Report Header property and Units column are unused.

Example of CSV:

40001,40002,MyFloat,MyString,Calc-CRC-32
9999,9999,3.1415,This is a String32 register,0x0

Store data in text format, with every data element row in the Report creating a line in the text file as "Name=Value". 

ARRAY START and NESTING START elements create a line in the text file as "# Name=" (no value).

Label elements create a line in the text file with just the Name value, not "=" or a value.

The Report Header property and Units column are unused.

Example of a TXT Report:

This is a label                     [a "Label" Output Format just uses name, not value]
40001=9999
# 1stArray=
40002=9999
# 1stObject=
MyFloat=3.1415
MyString="This is a String32 register"
Calc-CRC-32="0x0"

NOTE: Because the TXT Report file creates individual rows with Name=Value, it can be used to pass variables dynamically from the RTDB into a script. If the Report is defined to run a ProcessScript and the Bash script is written to 'source' the Report file, the file will be executed it as if it were a series of shell script variables being defined as part of the script operation.

Boolean

For Binary report, store whole byte of 0 or 1.
For text report, store "true" or "false".

Char-8 

When used with Process-RTDB-Report or Process-PBuf-Report: use only with numeric RTDB registers (for string registers, use one of the Text type output formats)

Take only the lower 8-bit byte of source register(s) (or a different byte, if using byte swapping).

For Binary or Google Protobuf report, store the byte.
For a text report, convert to an ASCII character and concatenate to a string of characters (from the number of source registers specified in the Count column, until the ASCII value evaluates to 0x00 null byte).

When used with Process-FILE-Report: 

Works like Text String format – store Max String Len characters to output file.

16bit Unsigned Integer 
32bit Unsigned Integer
16bit Signed Integer
32bit Signed Integer
32bit Floating Point

16 or 32-bit signed or unsigned integer types will yield the appropriate data output for text reports. (For Process-FILE-Report, the options are either Unsigned or Signed, regardless of size.)

For a Binary report, the 16 or 32 bits will be stored in order according to the Swapping option.

Text String 

For String-32 source register(s) → Binary report: store 32 bytes/register * Count of registers.

For String-32 source register(s) → text report: concatenate Count of registers into a single string.

For Integer source register(s) → Binary report: store the register size (bytes) * Count of registers (with byte swapping).

For Integer source register(s) → text report: convert all bytes in register size (bytes) * Count of registers into ASCII characters and concatenate all characters into a string, until reaching a 0x00 null byte.

(Use for text report types only) Take a 16 or 32-bit source register(s) and represent the bytes as ASCII "00" through "FF" as a string in the text output.

Unsigned 64bit Integer
Signed 64bit Integer
64bit Floating Point
Hexadecimal 64bit Integer

 64-bit types are the same as 16 and 32-bit types above.

(Process-FILE-Report only, used for text output types only)

Take four numeric octet values (from a 32-bit integer or two 16-bit integers) and output an IP address in dotted decimal notation, such as "192.168.1.1".

Label (Name text only, no data) 

(Use for "TXT (Property=Value)" report Output Mode only)

Store the value in the Name column (Process-RTDB-Report) or SEARCH-TEXT column (Process-FILE-Report) directly into the Report on its own line, with no "=" or register value. Note: Even though the RTDB address is not used, DataRegs Offset must point to a valid RTDB address.

The following output formats don't store data. They are used only in XML or JSON text reports to provide a hierarchical structure of data values. Note: Even though the RTDB address is not used, DataRegs Offset must point to a valid RTDB address. For the Process-FILE-Report, the SEARCH-TEXT is ignored for all four of these Output Formats.

NESTING START (NAME Only without Data) 

Create the start of a nested hierarchy of data values. The JSON object name or XML element name is taken from the Name column (Process-RTDB-Report) or ReplaceName column (Process-FILE-Report). For the Process-PBuf-Report, the name is not included in the payload, but can match the name of a sub-message in the Protobuf definition structure.

For JSON text report: Create the beginning of a JSON object:  "Name": {   unless this is an element inside an array. In an array, the Name is omitted and just a JSON object is created:  {

For XML text report: Create the beginning of an XML element:  <Name>

NESTING END (NAME Only without Data)

Create the end of a nested hierarchy opened by NESTING START.

For JSON text report: Close the JSON object with:  }

For XML text report: Close the XML element with:  </Name>   where the Name is taken from the Name column (Process-RTDB-Report) or ReplaceName column (Process-FILE-Report). This must be included in the NESTING END row and should be identical to the name used in the matching NESTING START.

ARRAY START (Begin JSON array, No Data)

Create the start of an array of data values. The JSON or XML arrayName is taken from the Name column (Process-RTDB-Report) or ReplaceName column (Process-FILE-Report). For the Process-PBuf-Report, the name is not included in the payload, but can match the name of an iterated field in the Protobuf definition structure.

For JSON text report: Create the beginning of a JSON array:  "arrayName": [

For XML text report: Create the beginning of an XML element with "array" tag:  <array Name="arrayName">

ARRAY END (End JSON array, No Data)

Create the end of an array opened by ARRAY START.

For JSON text report: Close the JSON array:  ]

For XML text report: Close the XML "array" element:  </array>

Create the start of an "IF" (optional) section in the report definition. This allows one or more data values to be included conditionally in the output report. More than one "IF" sections can be nested.

The following output formats are used for storing timestamp values, used for text reports only. Support is currently limited – contact Elecsys for more information on using these Output Formats.

YYYY-MM-DDTHH:MM:00 from Linux EPOCH Seconds UINT32

YYYY-MM-DDTHH:MM:00+TZN:00 from Linux EPOCH Seconds UINT32

Store RediGate Linux system time stored in a 32-bit RTDB register (seconds since 1970) as a formatted ISO date/time text, with or without timezone.

YYYY-MM-DDTHH:MM:00 from two encoded UINT32 Date(MMDDYYYY),Time(HHmm)

YYYY-MM-DDTHH:MM:00+TZN:00 from two encoded UINT32 Date(MMDDYYYY),Time(HHmm)

Store two UINT32 registers containing date (MMDDYYYY) and time (HHmm) as a formatted ISO date/time text, with or without timezone (seconds set to "00"). This is compatible with dates obtained from Daniels flow meter.

YYYY-MM-DDTHH:MM:SS from two INT32 Date(MMDDYY),Time(HHmmSS)

YYYY-MM-DDTHH:MM:SS+TZN:00 from two INT32 Date(MMDDYY),Time(HHmmSS)

Store two UINT32 registers containing date (MMDDYYYY) and time (HHmmss) as a formatted ISO date/time text, with or without timezone. This is compatible with dates obtained from Daniels flow meter.

YYYY-MM-DDTHH:MM:SS from Omni STRING-16 MM-DD-YYHH:mm:SS

YYYY-MM-DDTHH:MM:SS+TZN:00 from Omni STRING-16 MM-DD-YYHH:mm:SS

Take a date string obtained from an Omni flow meter report into a String register (as "MM-DD-YYHH:mm:SS") and store as a formatted ISO date/time text, with or without timezone.

Text-8 Chars only
Text-16 Chars only
Text-24 Chars only
Text-32 Chars only
Text-48 Chars only
Text-64 Chars only
Text-128 Chars only
Text-All Chars

These Output Formats may be used for Binary reports, to limit the output of a text field to a specified length, ensuring that the Binary report file remains a fixed width.

The following output formats are used only with Process-FILE-Report to extract a variable number of lines of data from a source text file. Omni Command 65 Event/Alarm report files use this method to represent event records, where the newest records are added to the top of the event section of the report, and older alarms appear further down the page. The event data may span multiple pages of an event report file, with a header row above the events on each page.

The procedure for using the LOOP option is a little complicated, but basically involves defining a TOP OF LOOP statement in the Report definition table to find the line of text just before the repeating "event" data, using SEARCH-TEXT to find the header text. The following Report statements process data on each line of "event" data, then the Jump to TOP OF LOOP entry returns to the previous TOP OF LOOP definition in the Report table to process the next "event" line of text.

Search for SEARCH-TEXT in order to find the matching row just above the event data lines in a text file. No output is produced, but a pointer will be set to the current line in the file.

If the next event row to be processed matches a row of text that has previously been processed, then event processing will stop, and the Report definition will continue following the "Jump to TOP OF LOOP" statement. (This is based on the assumption that newer events appear at the top, and older events are further down the page – we don't want to keep processing and publishing old events, only new events that haven't been published.)

Set the "Line Number" column in this row to zero (0) if there are multiple pages in the source text file, with a header row and events on each page, to allow for searching through events on multiple pages. If the next "event" line to be processed is a blank line (carriage return), search again for the SEARCH-TEXT on the next page to find the beginning of the next set of events (this assumes that each section of header+events on a page will be followed by a blank line).

Search for SEARCH-TEXT in order to find the matching row just above the event data lines in a text file. No output is produced, but a pointer will be set to the current line in the file.

This TOP OF LOOP option does not remember the last line of "event" text processed, and does not stop processing events when a matching row is found. It will only finish processing if the end of the text file is reached or if a blank line (carriage return) is reached.

If the "EVENT TOP OF LOOP" or "TOP OF LOOP w/o History" statement is used in this Report definition, upon reaching this statement, jump back to the TOP OF LOOP statement in the Report definition and continue processing another "event" line of text from the source text file.

If the calling Process uses a non-zero "DataReg" register, then the "DataReg Offset" column is treated as an offset from the starting DataReg register, for every row in the Report. The offset may be negative or positive (-65535 to 256000).

For instance, if a Process calls this Report with a DataReg=40001 (from a Master Channel/RTU), then a DataReg Offset of  5  will retrieve the value in register 40006 in the RTDB of that Channel/RTU. A DataReg Offset of  -10000  will retrieve the value in 30001.

If the calling Process has DataReg set to 0, then the "DataReg Offset" column is treated as an absolute register address in the Channel/RTU RTDB, for every row in the Report.

For instance, if the calling process uses DataReg=0, the DataReg Offset might be set to RTDB addresses 40006, 30001, etc.

Count of registers (starting at the RTDB register pointed to by DataReg Offset) to use for the value being processed in this row of the Report.

This is used in cases where one value (long integer, floating point, string) occupies more than one consecutive register address. (Remember that each row in the Report table handles only one data value or string.)

The Output Format determines how the source value on each row of the Report should be stored in the output file. 

See the section Automated Processing#Output Format Types for Report Rows for a description of the different output formats for individual data elements.

This option allows data coming from RTDB registers to be byte-swapped or word-swapped in order to represent the value correctly in either a Binary or text format Report output.

For instance, if the source RTDB type is 16-bit and the Count is 2 for a 32-bit integer, byte-swapping switches the order within registers, and word-swapping changes the order of the registers when they are assembled into a value.

Options are:

• No Swapping – the default order is LSB first, then MSB from the first register in "Count", then second registers, etc.
• Swap Bytes – MSB first, then LSB in registers.
• Swap Words – Last register in "Count," then first register.
• Swap Bytes and Words – Last register in "Count" is first, in MSB–LSB order.
• Swap DWords – All the "DWords" options are for 64-bit data. Swap DWords reverses the order of 1st and 2nd sets of 32-bits.
• Swap DWords,Bytes – Switch order of 32-bit words, plus MSB/LSB order.
• Swap DWords,Words – Switch order of 32-bit words, plus 1st/2nd register.
• Swap DWords,Words,Bytes – Switch order of 32-bit words, 1st/2nd register, and MSB/LSB order.

(Use only for text output modes)

If a "+" symbol is used for the Name column, then the Tag name of the RTDB register (or register number, if no Tag) for the DataRegs Offset register will be used in the output report associated with the data value (JSON tag, XML element, CSV header, etc.)

Otherwise, a hard-coded string in the Name column will be associated with the data.

(Use only for an XML text output mode)

Units is optional. If non-blank, this column value will be added to the XML data element as an attribute called "Units".

The three Scale columns are optional, allowing the source data value to be scaled before the final value is stored into the output Report. Only one operation is allowed per column and operations are applied in series (Scale_1, then Scale_2, then Scale_3, if they are non-blank). The output of the scale operation is cast to the data type of the source RTDB register. (Scaled operations are not allowed on 64-bit registers.) Scale operations are:

• + 0.0    (Add)
• - 7        (Subtract)
• * 3.14   (Multiply)
• / 5         (Divide)
• i 1.4      (invert the preceding value, then multiply by the number)

Examples (showing 2 or 3 Scale statements):

Convert Celsius to Fahrenheit:            * 9        / 5     + 32
Convert Fahrenheit to Celsius:             - 32     / 9     * 5
Calculate 3 / (register + 10):                 + 10     i 3

Enter a starting line number in the source text file to begin looking for the SEARCH-TEXT text identifier. The first line in the file is 1. If more than one line in the text file contains SEARCH-TEXT, you need to make sure the starting Line Number is set to find the correct text identifier, because searching will stop after the SEARCH-TEXT is found once.

Set the Line Number to zero (0) to start looking for SEARCH-TEXT and data elements at the current file pointer (immediately following the previous data element). Set SEARCH-TEXT to "?" to skip the search and immediately begin reading a data element at the current pointer.

Enter an Item Index from 1 to 255 of the whitespace-separated data element to be parsed, following the SEARCH-TEXT (or at the current file pointer, if Line Number=0). Search is skipped if SEARCH-TEXT is set to "?".

One or more printable text characters separated by white space are counted as separate indexed items.

For instance: Text file contains the following on a single line: "Pressure: 320 PSI   Temperature: 40 degF". If doing a search for "Pressure:", item index 1 is "320". Item index 4 following that same search is "40".

If Line Number is set to 0, the newline character at the end of a line of text does not stop the acquisition of the Item Index; i.e., an Item Index greater than 1 may scan across multiple lines of text to find the specified item. Otherwise (if Line Number>0), an Item Index of 1 may be found on the next line after SEARCH-TEXT, but any subsequent newline character will terminate the processing of a data element.

For instance: Text file contains two lines, "Data" and "aa bb cc", followed by other lines of text. Using a non-zero Line Number and SEARCH-TEXT of "Data" will find the word "Data" on the first of the two rows; then Item Index=1 will obtain "aa" on the next line for the data element; or Item Index=3 will obtain "cc"; but an Item Index greater than 3 will not wrap to any subsequent lines to find later data elements, because the second newline terminates the processing.

If the data element to be parsed begins in the leftmost column of the text file, there are several ways to obtain it.

• If the previous statement in the Report definition obtained the last element on the previous line, then set Line Number=0 and Item Index=1 to obtain the first item on the next line.
• If the previous line includes some fixed text, then set SEARCH-TEXT to find the last text string on the previous row, then Item Index=1 will get the first item on the next line.
• Or, if the item is on a specific row number in the text file, set Line Number to be the row of the text file, set SEARCH-TEXT to "?" (to skip searching), and set Item Index=1 to get the first element on that row.

(Use only for text output modes)

Max String Len is used if the Output Format of the data element is one of the Text types (ignored for numeric data element types). Beginning immediately after the SEARCH-TEXT is located (or set it to "?" to skip the search), the Item Index parameter will look through whitespace-separated characters to find the first printable character of the specified Item Index. Then, beginning at that character, the number of characters up to Max String Len will be taken for the data element. If a newline character (end of line) is reached before Max String Len, the string will be terminated at the end of line.

The Output Format determines how the source value on each row of the Report should be stored in the output file. 

See the section Automated Processing#Output Format Types for Report Rows for a description of the different output formats for individual data elements.

If the data element from the source text file cannot be converted into the Output Format, the resulting data will be stored as zero (0) for numeric entries, or "null" if the element can't be found. If the Output Format is numeric and the first character of the data element is a number, but trailing characters are non-numeric, the numeric digits will be handled properly and the subsequent characters will be discarded (for instance, processing "4mA" as an integer will store "4" and discard the "mA".

This option allows data coming from a source text file to be byte-swapped or word-swapped in order to represent the value correctly in either a Binary Report output (not applicable to text output modes).

Options are similar to the "Swapping" option for the Automated Processing#Process-RTDB-Report. Default byte order (No Swapping) is little-endian.

This is the text string to be searched for in the source text file. If Line Number > 0, begin on that row of the file. If Line Number = 0, begin searching in the file immediately after the previous data element.

Use "?" to begin parsing an element immediately following the previous data element (if Line Number = 0) or with the first element on a row of the source text file (if Line Number > 0).

Use a tilde followed by a register number (such as "~40001") to get the SEARCH-TEXT from the Tag Name of the register. Use @ symbol followed by a string register number (such as "@48001") to get the SEARCH-TEXT from the contents of a string register, up to 32 characters. The register is used from the RTDB indicated by the Channel/RTU in the Process row that triggered this Report to run.

(Use only for an XML text output mode)

Units is optional. If non-blank, this column value will be added to the XML data element as an attribute called "Units".

(Use with text output modes)

ReplaceName is used as the tag or element name associated with the data value in the output Report (similar to the "Name" column in the Process-RTDB-Report). If ReplaceName is blank, the SEARCH-TEXT is used for the element name instead.

Use a tilde followed by a register number (such as "~40001") to get the ReplaceName from the Tag Name of the register. Use @ symbol followed by a string register number (such as "@48001") to get the ReplaceName from the contents of a string register, up to 32 characters. The register is used from the RTDB indicated by the Channel/RTU in the Process row that triggered this Report to run.

If the RTDB Address is set to 0, then the data element is processed into the output Report file, as normal. 

But if the RTDB Address is greater than 0, the data element will instead be stored into that numbered register in the Channel/RTU defined in the Process row that triggered this Report. The RTDB address must be an absolute register address (not an offset). Ensure that the RTDB register type is compatible with the Output Format selected for each data element.

Note that because the Process-FILE-Report sends data to either the output Report or the RTDB register, if you want to send it to both places, the text searching and processing configuration must be entered twice, with and without the RTDB Address.

If the calling Process uses a non-zero "DataRegs" register, then the "DataReg Offset" column is treated as an offset from the starting DataRegs register, for every row in the Report. The offset may be negative or positive (-65535 to 256000).

For instance, if a Process calls this Report with a DataReg=40001 (from a Master Channel/RTU), then a DataReg Offset of  5  will retrieve the value in register 40006 in the RTDB of that Channel/RTU. A DataReg Offset of  -10000  will retrieve the value in 30001.

If the calling Process has DataReg set to 0, then the "DataReg Offset" column is treated as an absolute register address in the Channel/RTU RTDB, for every row in the Report.

For instance, if the calling process uses DataRegs=0, the DataReg Offset might be set to RTDB addresses 40006, 30001, etc.

Count of registers (starting at the RTDB register pointed to by DataReg Offset) to use for the value being processed in this row of the Report.

This is used in cases where one value (long integer, floating point, string) occupies more than one consecutive register address. (Remember that each row in the Report table handles only one data value or string.)

The Output Format determines how the source value on each row of the Report should be stored in the output file. This should match the field type (integer, float, string) that is defined for each Protobuf field in the message, as well as specifying the size of the value to be output (16-bit, 32-bit, etc.).

See the section Automated Processing#Output Format Types for Report Rows for a description of the different output formats for individual data elements.

This option allows data coming from RTDB registers to be byte-swapped or word-swapped in order to represent the value correctly in the Report output.

For instance, if the source RTDB type is 16-bit and the Count is 2 for a 32-bit integer, byte-swapping switches the order within registers, and word-swapping changes the order of the registers when they are assembled into a value.

Options are:

• No Swapping – the default order is LSB first, then MSB from the first register in "Count", then second registers, etc.
• Swap Bytes – MSB first, then LSB in registers.
• Swap Words – Last register in "Count," then first register.
• Swap Bytes and Words – Last register in "Count" is first, in MSB–LSB order.
• Swap DWords – All the "DWords" options are for 64-bit data. Swap DWords reverses the order of 1st and 2nd sets of 32-bits.
• Swap DWords,Bytes – Switch order of 32-bit words, plus MSB/LSB order.
• Swap DWords,Words – Switch order of 32-bit words, plus 1st/2nd register.
• Swap DWords,Words,Bytes – Switch order of 32-bit words, 1st/2nd register, and MSB/LSB order.

The Name column is not output directly in the Protobuf output payload, but by convention it is recommended to use the field names in the Protobuf definition. This will allow correlation between the ACE configuration and the Protobuf definition for understanding the data items in the message structure. See below for an example of configuring a Protobuf message using the Process-PBuf-Report table.

If a single "?" character is used in the Name column for a Publish report, then the field value will NOT be added to the message. The scaled value of the tag will only be written to an RTDB Address, if that column is configured with a numeric RTDB register. The "?" symbol has no function in a Subscribe report.

If this column is unused (such as for NESTING END or ARRAY END), it must still contain at least one character, such as a "+".

The PBuf Tag column contains the numeric field number for each field that is defined in the Protobuf message. The values in this column must match the Protobuf message definition in order to encode the output into a correct Protobuf payload. See below for an example. The PBuf Tag property has some specific rules, associated with the Google Protocol Buffers language structure.

• The PBuf Tag (field number) for non-repeated fields should be unique among all fields for that message (unique within the same level in the message). Typically, tag numbers start at 1 and run consecutively, but they don't have to be consecutive in the Protobuf definition.
• For a "repeated" field in the Protobuf definition, the PBuf Tag may be repeated at the same level in the message. See later bullet for more detail.
  
  
• Protobuf messages allow fields to be missing in the payload. On a Subscribe report definition, if a PBuf Tag is defined with only a numeric value in the Report structure but the received payload is missing the field, the Automated Processing will skip that value. However, if you wish to force the register (DataReg Offset) to a default value of zero for a missing field, you must append the letter "z" after the number. (A space can be included between the number and the "z", for readability.)
  
  Example: a Protobuf message includes field# 2. The Subscribe message is received, but field# 2 is not present in the payload. If the Report definition includes PBuf Tag of "2" which would have been saved to register 41201, the missing value will be skipped, and register 41201 is unchanged. But if the PBuf Tag is set to "2 z", then register 41201 is set to 0, due to the missing tag.
  
  
• If there is a nested sub-message as a field within a message, it can be defined in the following way:

Output Format: NESTING START, PBuf Tag: field number of the sub-message (its numeric position in the current level of the message)
Sub-message field elements, PBuf Tag: 1 through X (unique within the sub-message, but might duplicate other tag numbers at different levels in the main message).
Output Format: NESTING END, PBufTag: ignored (can be blank)
The SrcReg Count can be set to 1 for both NESTING START and NESTING END - it is ignored.

• If there is a repeated element within a message (including a repeated sub-message element), it can be defined in one of the following ways:

1. Include the repeated field multiple times in the Report definition, using the same PBuf Tag (field number) on each row. Typically, each row would reference a different statically defined DataReg Offset source register; or different sets of registers for repeated NESTING START elements. Or,
2. Use the Output Format ARRAY START/ARRAY END to define a variable array of elements. The array should be defined in the following way:

Output Format: ARRAY START, PBuf Tag: field number of the sub-message (its numeric position in the current level of the message), SrcReg Count: number of repeated elements to include, DataReg Offset: unused (but must be an integer).
Repeated element Output Format: use appropriate data type, PBuf Tag: Typically set to 1, DataReg Offset: RTDB address of the first register containing repeated data. Data must be in consecutive registers, and on each iteration through the array, the repeated field values will be taken from subsequent registers following DataReg Offset location.
Output Format: ARRAY END, PBuf Tag: ignored (can be blank), SrcReg Count: ignored (but must be an integer), DataReg Offset: unused (but must be an integer).

The three Scale columns are optional, allowing the source data value to be scaled before the final value is stored into the output Report. Only one operation is allowed per column and operations are applied in series (Scale_1, then Scale_2, then Scale_3, if they are non-blank). (Scaled operations are not allowed on 64-bit registers.) 

The Scale operations on a Publish message are applied to RTDB register values before storing or publishing. Scale operations on a Subscribe message are applied to the received value before storing to RTDB or writing to an RTU.

The output of all scale operations is cast to the data type of the source RTDB register. NOTE: This is important – if the source RTDB register is an integer type, then all subsequent values and operands in all Scale operations will be truncated to the integer value, which may lead to unexpected results. To force the intermediate Scale operations on integer values to use fractional values, include an "F" as the first character in the Scale_1 column, followed immediately by any additional operator (+-*/i), with no space. The "F" character is only recognized in the Scale_1 column.
Example: "F* 9" will multiply the source value by 9, but all Scale operations will be done in floating point math. If the Output Format is integer, the result of the last calculation will be truncated to an integer.

Decimal points are required only for values that are fractional. Scale operations are:

• + 0.0    (Add)
• - 7        (Subtract)
• * 3.14   (Multiply)
• / 5         (Divide)
• i 1.4      (invert the preceding value, then multiply by the number. Do not use "*" – the invert and multiply are both implied with the single "i" character.)

There can be a space between the operator and the number, for readability. (But there cannot be a space between the "F" and the operator.)

Examples (showing 2 or 3 Scale statements):

Convert Celsius to Fahrenheit:            F* 9        / 5     + 32    ("F" is used if values are integers)
Convert Fahrenheit to Celsius:             - 32     / 9     * 5        (no "F" is needed, if values are already floating point type)
Calculate 3 / (register + 10):                 + 10     i 3
      Explanation: take the source value and add 10. Then invert the sum to the denominator and multiply by 3.

If this column is non-zero for the Process-PBuf-Report on a Publish message, the scaled value will be output to the RTDB Address register and added to the output message. But if the Name column contains a single "?" character, then the scaled value will only be stored to the register but not added to the output message. The RTDB Address must be an absolute register address (not an offset). Ensure that the RTDB register type is compatible with the Output Format selected for each data element.

This column is not used for Subscribe messages.