The ‘DLOG_NEW_RECORDS’ command, described in this document, is the only command that must be implemented to receive datalog records from a SIXNET RTU. It is possible to also receive I/O register (real-time status) data as well, by implementing I/O transfer commands. In practice, however, we have yet to see an application where it was necessary to do both with one interface. Please be aware that datalog records are collections of I/O values that are merely reported with a time stamp. Current status may therefore be derived from reading the most current datalog record.
SIXNET RTUs are capable of responding as a master and a slave simultaneously. When RTUs are configured to issue these datalog record transfers as a master, they may be simultaneously used to receive I/O poll requests from another application program. When Ethernet communication is used, no collisions will result because the messages are sequentially processed from the Ethernet buffer. Of course, if serial ports are used, care must be taken in the design of the overall application to avoid collisions on the serial communications channel or to be tolerant of collisions through adequate retries for message transmissions.
We recommend that all three message formats be implemented to allow flexibility in the choice of communciations media. (The three formats are binary, hex, and fixed CRC.) See the details above.
Multiple (sequential) datalog records may be packed into a single message. Although it is possible to configure the SIXNET RTU to send only a single record in each message, it is far more efficient and a better system design to accept multiple records in each message.
SIXNET RTUs keep track of the last acknowledged message. If communication is interrupted, records may remain in the buffer awaiting transmission. We recommend configuring systems to send all unsent records during each transmission, and that the receiving interface accept many records in its buffer to be tolerant of lapses in communication.
Some SIXNET RTUs (particularly the VersaTRAK) are capable of storing multiple datalog files. It is recommended that the ‘File Identifier’ field be used as one of the message identifiers to accommodate multiple record type transfers. If fact, we recommend that three pieces of information be issued to identify data records:
the station number
the file identifier
the record sequence number (useful for avoiding receipt of duplicated records and detecting data gaps).
The format of the message identifies the number and type for data fields in the message. This information can be used to verify that the data received fits the expected format and will fit into the receiving database. It is assumed that the content of each data field is known. (The RTUs and the database have matching record definitions.)
SIXNET suggests that a configuration file or data array be used to identify each defined data record by station number and file identifier. By doing this, data can be error checked and stored in an appropriate manner. This suggestion will make your interface flexible enough to handle different record types from various remote stations.
The acknowledgement message, sent in response to the ‘DLOG_NEW_RECORDS’ command, has a field defined for sending a time value. If a time is present in the message, the clock in the remote station will be updated to be in synchronization with this value, and therefore with the clock in the central station. It is recommended that this value only be sent if the clock time is out of tolerance for your system. Constant clock synchronization is not recommended.
Resetting the clock can cause discontinuities or duplications in the time stamps in the records. (Consider the effect of setting the clock back for daylight savings time.) For this reason, it is recommended that the record sequence number be used as the primary record tracking field.
A sample program is provided in the file: sitelogt.zip
For more information about the SIXNET Universal Protocol, especially information about other available commands, please refer to the file: mst_udr.pdf on the SIXNET CD.