Table of Contents
...
| Data Process Table | Values |
|---|---|
| Channel | Master Channel used for process logic and obtaining RTDB data. |
| RTU | Field Unit address used for process logic and obtaining RTDB data. |
| Type | For the Generic-Registers process, the options include:
|
| CommStatReg | 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. |
| Report | Select one Report definition to define the structure of the output data report produced by this process row. |
| DataRegs | 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 |
| TrigMode | 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. |
| TrigReg | RTDB address in Channel/RTU containing some value to trigger on. See below for a discussion on the TrigMode options. |
| TrigValue | Constant value to use for trigger comparison, or RTDB register containing a value for "Compare Register" TrigMode. See below for a discussion on the TrigMode options. |
| TrigAdjust | 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:
|
| TrigWrap | 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. |
| Run | The Run value is unused in processing, but it can be used as part of the Report filename (MQTT topic) using the ${RUN#} variable. |
| 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. |
| COUNT DataRegs | (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. |
| Inhibit Reg | Unused |
| Inhibit Test | Unused |
| Proc-Logic | Unused |
| Comment | Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. |
...
- NONE
No modification of the TrigReg register. - REMOTE INCREMENT, REMOTE DECREMENT, REMOTE ZERO
When Report is generated, write a value to the field device via its Poll Table, using the Channel/RTU/TrigReg address. The value to be written is either the existing TrigReg value incremented or decremented by 1, or a zero (0). When using REMOTE DECREMENT, the value decreases down to zero and remains there (no wrapping).
Additional options:
TrigWrap contains the maximum value for the REMOTE INCREMENT option. If TrigWrap is set to a number >20000, it points to an RTDB register that contains the maximum value; otherwise, the TrigWrap column itself is the (constant) maximum value.
Parm1 contains the constant "WrapTo" value for the REMOTE INCREMENT option. After the value increments positively past the maximum value, it will be set to Parm1.
TrigWrap and Parm1 columns are unused for REMOTE DECREMENT or ZERO options.
For both INCREMENT and DECREMENT options, the TrigReg register value is set directly in the RTDB, in addition to writing the value to the remote device. - RTDB INCREMENT, RTDB DECREMENT, RTDB ZERO
When Report is generated, write a value to the RTDB register configured in Channel/RTU/TrigReg (not sent to the remote device). The value to be written is either the existing TrigReg value incremented or decremented by 1, or a zero (0). When using REMOTE DECREMENT, the value decreases down to zero and remains there (no wrapping).
Additional options:
TrigWrap contains the maximum value for the REMOTE INCREMENT option. If TrigWrap is set to a number >20000, it points to an RTDB register that contains the maximum value; otherwise, the TrigWrap column itself is the (constant) maximum value.
Parm1 contains the constant "WrapTo" value for the REMOTE INCREMENT option. After the value increments positively past the maximum value, it will be set to Parm1.
TrigWrap and Parm1 columns are unused for REMOTE DECREMENT or ZERO options.
Read-ProtoBuff-Payload Process
The Read-ProtoBuff-Payload process object is used for parsing Google Protobuf-formatted payload messages, typically received through an MQTT subscription.
To publish a Google Protobuf payload, see the Generic-Registers process object instead.
Attributes | Function |
|---|---|
| Object Type | Read-ProtoBuff-Payload |
| Parent(s) | System → Clients → Automated_Processing → Processes |
| Instance | 0 |
Every row in the Process table points to a Report definition that describes a received Protobuf message. Therefore, the Reports section and at least one Report definition must be defined before the Data Process Table can be configured.
Data Process Table | Values |
|---|---|
| Channel | Master Channel used for storing RTDB data. |
| RTU | Field Unit address used for storing RTDB data. |
| Type | For the Generic-Registers process, the options include:
|
| CommStatReg | 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. |
| Report | Select one Report definition to define the structure expected from the subscribed data for this process row. |
| DataRegs | 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 Read-ProtoBuff-Payload 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 Read-ProtoBuff-Payload 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). |
| TrigMode | The TrigMode option selects a method to use in response to a receiving and parsing a Protobuf payload message. If either of the "WRITE" options are selected, it can be used by another process to indicate that we have received a message, and perhaps to take some further action. TrigMode options are:
|
| TrigReg | RTDB address in Channel/RTU to write a trigger value, indicating a received message, if configured by TrigMode. |
| TrigValue | If TrigMode selects a trigger action, this should either be a constant value to write, or an RTDB register address containing a value to write. |
| TrigAdjust | Unused |
| TrigWrap | Unused |
| Run | Unused |
| Parm1 | Unused |
| Parm2 | Unused |
| Inhibit Reg | Unused |
| Inhibit Test | Unused |
| Proc-Logic | Unused |
| Comment | Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. |
Device TimeSync Process
The Time-Syncs process object uses special program logic to synchronize the clock in either an Omni Modbus-compatible flow computer or an Allen Bradley PLC.
...
| Data Process Table | Values |
|---|---|
| Channel | Master Channel of the Omni or Allen Bradley device. |
| RTU | Field Unit address useof the Omni or Allen Bradley device. |
| Type | For the Time-Syncs process, the options include:
|
| CommStatReg | 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. |
| Report | Unused |
| DataRegs | 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). |
| TrigMode | Unused |
| TrigReg | 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). |
| TrigValue | Constant value to write to the device after the time has been synchronized. The value is written via the RTDB register (and Poll Table) specified in the TrigWrap column. This can be used, for instance, to write to the "Reset Power Failed" flag (Omni register 1713). |
| TrigAdjust | Unused |
| TrigWrap | RTDB register to write the TrigValue after the time has been synchronized (sent to the device via the Poll Table). |
| Hour | (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. |
| 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. |
| Parm2 | Unused |
| Inhibit Reg | Unused |
| Inhibit Test | Unused |
| Proc-Logic | Unused |
| Comment | Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. |
...
| Attributes | Function |
|---|---|
| Object Type | Heart-Beat-Monitor |
| Parent(s) | System → Clients → Automated_Processing → Processes |
| Instance | 0 |
Every row in the Process table handles the heartbeat monitoring for one field device. The Heart-Beat-Monitor process is an exception, in that it does not require a Report object to be defined.
| Data Process Table | Values |
|---|---|
| Channel | Master Channel used for the PLC. |
| RTU | Field Unit address used for the PLC. |
| Type | For the Heart-Beat-Monitor process, the options include:
|
| CommStatReg | 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. |
| Report | Unused |
| DataRegs | Unused |
| TrigMode | Unused |
| TrigReg | RTDB address in Channel/RTU containing the heartbeat value polled from the PLC. |
| TrigValue | Constant number of seconds, after which an unchanging heartbeat value will trigger the fail condition and send MQTT death certificate. |
| TrigAdjust | Unused |
| TrigWrap | Unused |
| Run | Unused |
| Parm1 | Unused |
| Parm2 | Unused |
| Inhibit Reg | Unused |
| Inhibit Test | Unused |
| Proc-Logic | Unused |
| Comment | Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. |
...
| Data Process Table | Values |
|---|---|
| Channel | Master Channel of the Omni Modbus unit used for process logic and obtaining RTDB data. |
| RTU | Field Unit address of the Omni Modbus unit used for process logic and obtaining RTDB data. |
| Type | For the Omni-Modbus-Archives process, the options include:
|
| CommStatReg | 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. |
| Report | Select one Report definition to define the structure of the output data report produced by this process row. Because the Omni-Modbus-Archives process deals with Modbus register-based polling, the Report must be a Process-RTDB-Report type. |
| DataRegs | 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. |
| TrigMode | Unused |
| TrigReg | RTDB address in Channel/RTU containing the first of three registers containing the Max, Current, and Requested Record for the archive. |
| TrigValue | Unused |
| TrigAdjust | Unused |
| TrigWrap | Unused |
| Run | The Run value is unused in processing, but it can be used as part of the Report filename (MQTT topic) using the ${RUN#} variable to identify the run number if the flow meter contains archives for multiple flow. |
| SOS-Enable | (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. |
| Parm2 | Unused |
| Inhibit Reg | Unused |
| Inhibit Test | Unused |
| Proc-Logic | Unused |
| Comment | Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. |
...
| Data Process Table | Values |
|---|---|
| Channel | Master Channel of the Omni Modbus unit used for process logic and obtaining CMD 65 file data. |
| RTU | Field Unit address of the Omni Modbus unit used for process logic and obtaining CMD 65 file data. |
| Type | For the Generic Registers process, the options include:
|
| CommStatReg | 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. |
| Report | Select one Report definition to define the structure of the output data report produced by this process row. Because the Omni-Cmd65-File process deals with ASCII text files, the Report must be a Process-FILE-Report type. |
| FileNameReg | (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). |
| TrigMode | Unused |
| TrigReg | RTDB address in Channel/RTU containing data to trigger when the raw ASCII text file has been acquired and is ready to be processed.
|
| TrigValue | RTDB register containing CRC-32 of the raw ASCII file, stored by the Modbus Poll Table (CMD 65) after completing the read. Used by Omni-Cmd65-File process to determine when the report is available for processing – after CRC-32 changes, process and publish the Report. |
| TrigAdjust | Unused |
| ACK Register | (This is the "TrigWrap" parameter.)
|
| HistRecord | (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. |
| SOS-Enable | (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. |
| Count HistRecords | (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. |
| Inhibit Reg | This is a Boolean register in the RTDB which is used for certain types of historical archives (Snapshot, Status, Product, Alarm, Measurement Audit, System Audit, Initialization), to prevent more than one archive request from operating at the same time. Each of these report processes uses Omni register 16303 as the Report Command register, so the Omni-Cmd65-File process will set the Inhibit Reg while one archive file is being retrieved and clear the register when finished, so other processes can acquire their own archive. |
| Inhibit Test | Unused |
| Proc-Logic | Unused |
| Comment | Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. |
...
| Definition Table | Values |
|---|---|
| DataReg Offset | 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. |
| SrcReg Count | 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.) |
| Output Format | 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 17727489 for a description of the different output formats for individual data elements. |
| Swapping | 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:
|
| Name | 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 "+". |
| PBuf Tag | 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.
Output Format: NESTING START, PBuf Tag: field number of the sub-message (its numeric position in the current level of the message)
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). |
| Scale_1 Scale_2 Scale_3 | 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. Decimal points are required only for values that are fractional. Scale operations are:
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 + 3232 ("F" is used if values are integers) |
| RTDB Address | 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. |
| Comment | Unused column that allows a comment to annotate each row in the Report Definition table. |
The Report definition should match the Google Protobuf message definition. The Publish and Subscribe report definitions will typically be exact copies of each other, if a RediGate is both the publisher and the subscriber of the same message. The only necessary difference is that the the Output Mode should be either "Publish" or one of the "Subscribe" options. (There might be cases where the Report contents are different, such as if the Publish message includes a conditional "IF" section.If a Subscribe report receives data with a field# (PBuf Tag) that isn't included in the Report definition, it will be discarded.
Example of Process-PBuf-Report Definition
...