Communication Driver Log-Enabled Variables
All of the standard drivers have 7 variables that may be logged. When recorded in a report, these allow you to monitor driver communications over time to spot problems or ensure that response times are acceptable.
| Logged Variable |
Description |
|---|---|
|
1. ErrorValue |
An error value or code associated with a driver's communication error. |
|
2. FailedCount |
Incremented on each communication error. |
|
3. FailedRetryCount |
Incremented if failure occurs on a retry. Drivers will usually retry more than once before designating an error to be an "error on retry". Thus, this count will always be less than or equal to the FailedCount. |
|
4. SuccessCount |
Count for successful reads and writes, incremented on each successful operation. |
| 5. Quality | A mathematically derived indication of communication error rates. Used to show the driver's overall "health". (1) |
|
6. ResponseTime |
The time it takes the PLC/RTU to receive a command, process it and send a response. (2) |
|
7. ErrorAddress |
If an address was associated with the error, it will be recorded here. |
A publicly accessible variable, CommStatsTimeStamp, holds the most recent timestamp that was used to update these variables and write them to a DAT file.
Monitoring Driver Health and Errors
To view errors, use the Reports Page. Two reports are standard for all communications drivers. The Driver Communication Error Detail Report and the Driver Communication Summary Report. Both are described in Report Types Described.
You can also place the appropriate Show Statistics Button Widget on a page to monitor the values in real-time.
On a busy system, it is dangerous to use these properties in expressions. SuccessCount and FailedCount in particular update with every read. Excessive RPC traffic may result, slowing your overall system performance.
(1) Calculation of Quality:
Quality is an indication of a driver's ability to communicate without errors. The value ranges between 0 and 1 where the closer the quality is to 1 (100%) the fewer communication errors are happening. You will need to determine what an acceptable level of quality is for your situation. To put it simply, the closer the quality is to 1, the better the driver communication.
On an initial, successful communication with a device, a quality of 1 (or 100%) is recorded. If subsequent communications attempts end with errors, the level of quality drops according to the following formula. Successful communications serve to then raise the level of quality back to a maximum of 100%.
You may find that the quality calculation changes through the day. This might indicate interference from a source that can then be tracked down.
The quality calculation formula:
Q = Q * qF + (1 - qF) * (1 - !Error)
Where:
Q = Quality
qF = Quality Factor
Error is a Boolean stating whether the driver reported an error state.
The default Quality Factor is .99 & all drivers start with a default Quality of 1.
Every time the driver completes an operation, the quality is recalculated.
Thus, when it first starts and does a successful operation:
Q = 1 *.99 + .01*1 = 1
When an error occurs, Q = 1*.99 = .99
If a subsequent error occurs, Q = .99*.99 = .9801
If a subsequent success occurs, Q = .9801 *.99 + .01*1 = .980299
The quality value over time will reflect the drivers overall health. It should always be a value between 0 & 1.
Quality includes all errors including any low level errors, retries, or addressing errors.
(2) Response Time
Response Time is calculated with the formula:
ResponseTime = EndTime - StartTime - XmitTime - RcvTime
Where:
XmitTime is the time it took to transmit any data
RcvTime is the time it took to receive any data, based on
- the number of bytes sent,
- the baud rate,
- parity,
- data bits and stop bits,
- whether there is an echo expected,
- whether RTS key delays are used.
The resulting Response Time is the time it took the PLC/RTU to receive a command, process it and send a response.
Calculation properties Calc tab
