Communication via SIKONETZ 5
AP10S
Date: 04.09.2017 Art. No. 87826 Mod. status 269/17 Page 23 of 48
Error due to device status
Table 16: SIKONETZ5 error codes
6.6 Communication errors
Error states of the slave are signified with the status word.7 = 1.
Every error must be acknowledged with control word.5 = 0/1 or by pressing the key. If the
cause of the error has not been resolved at the time of acknowledgment, the error will not be
reset or triggered anew, resp.
Errors that have not been acknowledged can be read via a read command on Parameter FDh:
Error telegram. The error code will be output (see chapter 4.5.2: Errors and 6.5.1: SIKONETZ5
error codes).
A list of errors occurring is output in Diagnosis (see chapter 4.6.4).
6.7 Communication monitoring
6.7.1 Bus-Timeout
Bus timeout monitoring is activated by configuring a valid time value (>0) for timeout (see
parameter 02h: Bus Timeout).
The first telegram received by the slave starts time monitoring.
Every new telegram recognized as valid by a slave (correct check sum) triggers time
monitoring.
If timeout occurs, this will result in the Timeout SIKONETZ5 error.
After establishing cyclic communication between master and slave, this function can detect a
broken cable of the connection line for instance and signal the defect.
6.7.2 Programming interlock
Programming interlock is controlled via parameter 0Eh: Configuration programming mode. This
parameter being enabled, the interlock must be canceled prior to write access to a lockable
parameter (see entry at the relevant parameter) by applying a write access to parameter A8h:
Programming mode. Correspondingly, the interlock should be enabled again immediately after
a write access.
This mechanism enhances protection against unintentional parameterization.
Write access to locked parameters is replied with "Error due to device state" (see chapter
6.5.1: SIKONETZ5 error codes).
To Next Page
Loading...
