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 CodesException 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 TagThe 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
This is another example, written in VBScript (Elipse E3 and Elipse Power): ' TagExc Tag's OnRead event
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
This is another example, written in VBScript (Elipse E3 and Elipse Power): ' Note: For this example, consider TagExc
|