Get MBLogic at SourceForge.net. Fast, secure and Free Open Source 
	software downloads

Help Topics

Topic Details for Communications

Help - Communications Errors


Overview

Communications errors come in several differnt types:

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:

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:

See the documentation on system configuration for more details.