Reading the Last Exception Code

<< Click to Display Table of Contents >>

 

Reading the Last Exception Code

As already mentioned on this Manual, Special Tags for reading the last exception code are used to read the last exception code sent from a certain slave device.

Such codes are automatically stored by this Driver in internal registers, which can then be accessed using this Tag. In addition, at each successful communication with a certain device where no exception was returned, this Driver automatically zeroes the associated register.

 

Exception Codes

Exception codes are used by a slave device (PLC) to report a failure when executing a certain function. Slave devices do not return exceptions in case of communication failures, a situation where these devices simply do not respond. Exception codes are returned by slaves in situations where a master request, such as the case of this Driver, was successfully received, but could not be executed for any reason, such as trying to read or write to a non-existent register. In this case, the returned exception code indicates the type of error occurred, that is, the reason that this Driver's request, although correctly received, could not be completed.

The specification of Modbus protocol defines nine exception codes. The list of protocol's default exceptions can be checked on topic List of Default Exceptions of the Modbus Protocol. In addition to these codes, some manufacturers define additional codes, specific to their devices. Such codes must be documented on a device's manual. If they are not, please check with manufacturer's technical support.

 

String Configuration

Device: Numerical value of device's Id (Slave Id) followed by a colon, such as "1:", "2:", "3:", and so on

Item: "LastExceptionCode"

 

Numerical Configuration

B1: Slave device's address (Slave Id)

B2: 9999

B3: Not used, can be kept in 0 (zero)

B4: Not used, can be kept in 0 (zero)

 

Values returned on Block Elements:

Element 1 (index 0): Exception code returned by a device. For more information, please check topic List of Default Exceptions of the Modbus Protocol

Element 2 (index 1): N2/B2 parameter of the I/O Tag generating this exception

Element 3 (index 2): N3/B3 parameter of the I/O Tag generating this exception

Element 4 (index 3): N4/B4 parameter of the I/O Tag generating this exception

Element 5 (index 4): Size parameter of the I/O Tag generating this exception

Element 6 (index 5): Device parameter of the I/O Tag generating this exception

Element 7 (index 6): Item parameter of the I/O Tag generating this exception

 

Using a Special Tag

The most common usage for this Tag during a normal scan of function Tags is via an exception Tag's OnRead event. In this case, a script must first reject null values, because these values indicate that exceptions were not received. Next, users can handle that exception by executing the adequate procedures, according to the received code. It is advisable to zero the exception register when leaving a script, to indicate that this exception was already handled. The next example is written in Elipse Basic (Elipse SCADA).

// TagExc Tag's OnRead event
// Note: For this example, consider TagExc
// with automatic reading and writing enabled
 
If TagExc == 0
  Return
EndIf
 
If TagExc == 1
  ... // Handles exception 1
ElseIf TagExc == 2
  ... // Handles exception 2
Else
  ... // Handles all other exceptions
EndIf
 
TagExc = 0 // Zeroes the exception register

 

The next example is written in VBScript (Elipse E3 or Elipse Power).

' TagExc Tag's OnRead event
' Note: For this example, consider TagExc
' with automatic reading and writing enabled
 
Sub TagExc_OnRead()
  If Value = 0 Then
    Exit Sub
  End If
 
  If Value = 1 Then
    ... ' Handles exception 1
  ElseIf Value = 2 Then
    ... ' Handles exception 2
  Else
    ... ' Handles all other exceptions
  End If
 
  Value = 0 ' Zeroes the exception register
End Sub

 

In writing operations by script, on the other hand, where users must test for returned exceptions right after sending a command, users must first zero the exception register. That avoids an eventual exception provoked by a writing command to be confused with another pre-existing one. Execute the writing operation and test a Special Tag's value, which must return 0 (zero) if no exception was received. In case it returns a value different from 0 (zero), then users can properly handle that received exception. The next example is written in Elipse Basic (Elipse SCADA).

// Note: For this example, consider TagExc
// with automatic reading and writing enabled
// and TagVal with automatic writing disabled
 
TagExc = 0 // Zeroes the exception register
 
TagVal.WriteEx(10) // Writes the value 10
 
If TagExc <> 0
  ... // Handles this exception
EndIf

 

The next example is written in VBScript (Elipse E3 or Elipse Power).

' Note: For this example, consider TagExc
' with automatic reading and writing enabled
' and TagVal with automatic writing disabled
 
' Zeroes the exception register
Application.GetObject("Tags.TagExc").Value = 0
 
' Writes the value 10
Application.GetObject("Tags.TagVal").WriteEx(10)
 
If Application.GetObject("Tags.TagExc").Value <> 0 Then
  ... ' Handles the exception
End If

 

NOTE

This Special Tag returns, in addition to an exception code returned on Element 0 (zero), also Tag parameters whose communication provoked that exception. If this information is not needed, users can read the same register using a simple Tag, or a PLC Tag in Elipse SCADA, without using a Block Tag. In this case, all recommended procedures remain the same.

Was this page useful?