Reading the Last Exception Code

Driver Modicon Modbus

Reading the Last Exception Code

Top  Previous  Next

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 (in case of a 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 a 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 Protocol's Default Exceptions. In addition to these codes, some manufacturers define additional codes, specific to their devices. Such codes must be documented on 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. Example: "1:", "2:", "3:", etc.

·Item: "LastExceptionCode"

 

Numerical Configuration

·B1: Slave device's address (Slave Id)

·B2: 9999

·B3: Not used, can be left in zero

·B4: Not used, can be left in zero

 

Values returned on Block Elements:

·Element 1 (index 0): Exception code returned by a device (please check topic List of Protocol's Default Exceptions)

·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. Please check the following example, 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

 

This is another example, written in VBScript (Elipse E3 and 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. Please check the following example, 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

 

This is another example, written in VBScript (Elipse E3 and 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 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 (a PLC Tag in Elipse SCADA), without using a Block Tag. In this case, all recommended procedures remain the same.

 
Has this section of the documentation helped you configure this Driver?
Yes No
Comments (optional):