Fieldbuses – General Part
Terminology
Output telegram is the protocol-specific telegram (safety PDO) from the safety controller to the safe field device. This telegram contains the output data to the safe field device. | |
Input telegram is the protocol-specific telegram (safety PDO) from the safe field device to the safety controller. This telegram contains the input data from the safe field device. | |
Driver instance: For each configured logical I/O, code is created for a driver instance of the supported protocol type (for example, a driver instance of type |
Interface description
The safety controller monitors the transmission of the I/O data to and from the safe field device. A logical I/O is generated by the development system for each safe field device. A driver instance is created automatically for each logical device.
With the creation of the driver instance, implicit code is generated resulting in the following for input or output variables:
Phase 1 (input phase): Processing the input telegrams (implicit)
The driver instance receives the input telegram and checks this in accordance with its protocol specification, for example PROFIsafe.
The input data or, in the event of an error, the substitute values are copied into the mapped input variables of the application.
Phase 2: Processing the user application
The output data is generated in dependence of the input data and the state of the application.
Phase 3 (output phase): Processing the output telegrams (implicit)
The mapped output data of the application are handed over to the driver instance. The driver instance generates the output telegram in accordance with its protocol specification and sends this to the safe field device.
Default behavior of the driver
Notice Drv_1 (start of the application)
When the application is started, it can happen as of the first cycle that process data is exchanged between the field and the application. The use of FBs with a startup lock (S_StartReset = FALSE) or the implementation of other system and application measures (see Safety User Manual. "Rules for using PLCopen-compliant function blocks") makes sure that any unexpected (or unintentional) startup of the machinery does not occur when the application starts.
Notice Drv_2 (communication error at start)
By default, the usual communication errors at the start do not prevent the automatic start of the process data communication. Instead, it is only delayed. See Input for automatic acknowledgement of startup errors (auto-ack-startup-error).
The default behavior of the driver for starting up after a reset or for restarting after a communication error is defined by the initial value of the respective input. In order to overwrite the default behavior, the function block in the application must be called and the respective input must be set accordingly:
The automatic beginning of the process data transmission after the start is prevented by the program by calling the function block in the application and setting the input auto-ack-startup-error to FALSE (see. Input for automatic acknowledgement of startup errors).
The automatic resumption of the process data transmission is enabled by the program by calling the function block in the application and setting the input auto-ack-interrupt input to TRUE (see. Input for automatic acknowledgement after interruption).
Input for automatic acknowledgement of startup errors
Name | Data Type | Initial Value | Description, parameter values |
|---|---|---|---|
<auto-ack-startup-error> |
|
| Startup behavior after a reset (commands: Reset Cold – Safety and Restart) of the application, e.g. PowerON.
|
Important
Please note Notice Drv_2 (communication error at start): The initial value for the input for the startup behavior after a reset is TRUE. All errors for the startup behavior are acknowledged after a reset.
Then the process data communication begins as soon as the initial communication error has disappeared.
Important
Please note Notice Drv_1 (start of the application): Setting auto-ack-startup-error to FALSE does not prevent the automatic start of the process data communication. If no errors occur during startup the stack can start automatically, even if auto-ack-startup-error is set to FALSE. The user must take this into consideration in the application.
Input for automatic acknowledgement after interruption
Name | Data Type | Initial Value | Description, parameter values |
|---|---|---|---|
<auto-ack-interrupt> |
|
|
|
Notice Drv_3 (input for automatic acknowledgement after interruption)
Caution
If <auto-ack-startup-error> and <auto-ack-interrupt> are TRUE, then all errors are acknowledged. This is sensible only in certain exceptional cases.
Restart behavior following a communication error
The initial value for the input for the restart behavior after a communication error is FALSE; the error with regard to communication transmission is not automatically acknowledged.
An explicit call of the function block instance with corresponding connection of the inputs is necessary.
Input for acknowledgement edge (manual acknowledgement)
Errors can be acknowledged with a positive edge on the input for acknowledgement, provided the (output for the acknowledgement request) is set.
If all errors are acknowledged automatically (which is sensible only in exceptional cases), then this input is not required and can remain unconnected.
If no acknowledgement is currently requested, the input is ignored: Therefore the same signal can be connected to the input for the acknowledgement edge of all driver instances in order to realize a non-specific acknowledgement of communication problems.
Name | Data Type | Initial Value | Description, parameter values |
|---|---|---|---|
<ack-edge> |
|
| The resumption of the safety function is acknowledged after an error with a rising edge on the input. |
Notice Drv_4 (ack-edge)
Caution
The <ack-edge> input is used for acknowledgement by the user. It is not to be set by the program, but connected with an input signal.
Tip
The <ack-edge> input requires a rising edge. After the user has stopped the acknowledgement it should go FALSE again in order to conclude the acknowledgement. Only then is the next acknowledgement requested at the input <ack-req> on the next communication error.
Output for acknowledgement request
The output is TRUE if a communication error has occurred (startup error or interruption) and this only needs to be manually acknowledged in order to resume communication.
If the output <ack-req> is TRUE, then the connection requires an acknowledgement by the user. Normally the user is informed that his acknowledgement is required (for example with the aid of an exchange variable to the standard controller and display in the visualization)
If the output is set, the error can be acknowledged at the input for acknowledgement.
Name | Data Type | Initial Value | Description, parameter values |
|---|---|---|---|
<ack-req> |
|
|
Tip
The display at the output ack-req can take place only if:
The communication error is not acknowledged automatically, i.e. if <auto-ack-startup-error> or <auto-ack-interrupt> is
FALSE.The <ack-edge> input is currently
FALSE, i.e. if a manual acknowledgement has been started but not concluded yet.
Therefore, if a new communication problem occurs while the user is still acknowledging a problem that occurred previously, then the new communication problem is only displayed and processed after the user has completed the acknowledgement of the previous problem.
Explicit calling of the function block
If the function block is explicitly called by the user in the application (phase 2), then the function block inputs can be set and the function block outputs can be read, although the function block itself does not execute any operations. For each driver instance, there can be at most one call in the application.
The function block outputs of the driver instance can be read regardless of a call.