MBLogic
for an open world in automation
Help - Communications Errors
Overview
Communications errors come in several differnt types:
- Connection errors.
- Command errors.
Communications errors can be viewed using the "status" web based monitoring interface. They are also reported in the system data table where they may be accessed by the soft logic program or other systems.
Types of Errors
Connection Errors
Client connection faults are reported in the status monitoring web page and in the data table (more details below). Servers do not initiate connections, so they do not report the inability to create a connection.
Connection faults codes are protocol dependent, to the degree that they must not duplicate the error codes used for the protocol on that connection.
Command Errors
Command errors are errors or faults which are defined by the particular communications protocol being used. These are typically caused by either an incorrect configuration or a problem in a remote client. Connection faults are related to problems establishing or maintaining a connection between a local client and a remote server.
Status and Error Codes
Connection Status and Error Codes
| Code | Description |
|---|---|
| starting | The connection is in the process of starting. |
| running | The connection is running normally. |
| stopped | The connection is stopped. |
| faulted | The connection is faulted. |
Client Command Status Codes
| Code | Data Table Value | Description |
|---|---|---|
| ok | 0 | No errors |
| badfunc | 1 | Unsupported function |
| badaddr | 2 | Invalid address |
| badqty | 3 | Invalid quantity |
| deviceerr | 4 | Device error |
| frameerr | 5 | Frame error |
| connection | 255 | Client connection lost |
| timeout | 254 | Message time out |
| servererr | 253 | Undefined server error |
| badtid | 252 | TID Error |
| noresult | 251 | No result |
Error Reporting
Web Based Status Reporting
Live fault information is displayed on the status web pages. This includes connection and command errors, as well as a log of past errors. See the documentation on the status web pages for more information.
Data Table Reporting
In the communications configuration, the user can specify a set of addresses for each client to be used for reporting client communications errors. Each time an error is detected, these addresses are updated to indicate the error. This error information may be read using normal protocol commands to detect if an error is present, and what the error is.
The same error is reported in all four memory types (coil, discrete input, holding register, input register) in the system data table. This allows an error to be monitored in a manner which is convenient to any configuration.
When an error is detected, the specified coil and discrete input are turned on, and the appropriate numeric code is written to the holding and input registers.
If error information is present, it will not be reset or erased unless specifically requested. However, newer errors will automatically overwrite older error information.
The error reporting addresses may be located anywhere in memory. It may be convenient to place them adjacent to other data which is being read to permit the data and error indication to be read in a single read operation.
Error reporting is on a per-connection basis. This means that if a connection uses multiple commands, then errors associated with any of these commands will be stored in the same set of fault addresses. However, a separate set of addresses should be used for each connection.
Resetting Error Codes
Error indication can be reset in two ways:
- By overwriting the data table address directly.
- By writing to a fault reset coil.
Addresses used to report faults are normal data table addresses and may be overwritten using normal protocol commands. However, this requires several write operations, and the server protocol may not permit writing to all address types.
In addition to simply overwriting a fault address, a special set of coil addresses has been reserved for resetting fault information. In the data table, a range of coil addresses is regularly monitored to see if any of them have been turned on. If one or more has been turned on, the system will look to see if they have been associated with a particular client fault configuration. If so, the associated fault indication addresses (as well as the reset coil itself) will be reset.
Any coils which are in the monitored range will be turned off regardless of whether or not they are associated with a fault configuration. This means that coils which are not used for fault reset may still not be used for any other purpose. Writing to a coil in the monitored range but which is not configured will not result in an error, but it will result in that coil being automatically reset.
The monitored coils are located in the upper 256 coil addresses (65279 to 65535). They are monitored approximately once per second. This means that it may take up to approximately 1 second for a fault reset to complete once it has been requested.
Resetting a fault does not automatically re-initialise any communications. It simply clears the fault reporting memory. It also does not affect the display of faults on the status web pages.
Configuration
Faults reporting is configured via the system configuration file. The following items can be configured:
- The addresses (coil, discrete input, holding register, input register) used for reporting faults.
- The address used for resetting a fault.
See the documentation on system configuration for more details.