SF_SafetyRequest
Help version 2.0 / Issue date: 2024.04
The following description is valid for the function block SF_SafetyRequest_V2_0z, Version 2.0z (where z = 0 to 9).
Short Description
| The safety-related SF_SafetyRequest function block supports the function "Request of a safety-related function" in an application (e.g., safe stop or safely limited speed).Depending on the status at input S_OpMode, the safety-related function block requests the safety-related function at the periphery.Based on the signal for requesting a safety-related function (at the S_OpMode input) and the feedback signal about its correct execution (at the S_Acknowledge input), the S_SafetyActive output signal is controlled. This output signal is typically used to send a signal confirming the requested operating mode being activated to a subsequent safety-related function block.The maximum permissible response time within which confirmation is expected must be parameterized at the MonitoringTime input and is monitored by the safety-related function block.The function block thus serves as interface between the functional safety system (consisting of the Sicherheitssteuerung and safety-related input/output modules) and the connected safety-related periphery, for example a safety-related drive.
Hinweis
A start-up inhibit and restart inhibit are provided in the SF_SafetyRequest function block. The
start-up inhibit can be specified at the S_StartReset input, the restart inhibit cannot be deactivated. Refer to the topic "Functional description" for details. An active start-up inhibit/restart inhibit must be removed manually by a positive signal edge at the Reset input. |
|
Block Icon
|  |
Inputs
| Activate
Short description | Value |
State-controlled input for activating the function block. Data type: BOOL Initial value: FALSE |
-
FALSE: Function block inactive.
-
TRUE: Function block activated.
|
Refer to the topic "Activate" for details.
S_OpMode
Short description | Value |
State-controlled input for requesting the execution of a safety-related function in the connected safety-related periphery.Data type: SAFEBOOL Initial value: SAFEFALSE |
-
SAFEFALSE: Request of the safety-related function in the connected safety-related periphery
-
SAFETRUE: No request of the safety-related function in the connected safety-related periphery
|
Refer to the topic "S_OpMode" for details.
S_Acknowledge
Short description | Value |
State-controlled input which processes the status feedback of the connected safety-related periphery.Data type: SAFEBOOL Initial value: SAFEFALSE |
-
SAFEFALSE: Feedback of the connected safety-related periphery that no safety-related function is executed
-
SAFETRUE: Feedback of the connected safety-related periphery about execution of the safety-related function
|
Refer to the topic "S_Acknowledge" for details.
MonitoringTime
Short description | Value |
Input for specifying the maximum permissible response time between the request of the safety-related function at the S_OpMode input and confirmation of its execution at the S_Acknowledge feedback input.Data type: TIME Initial value: #0msIf the specified time value is exceeded, the Error output switches to TRUE and the S_Acknowledge enable output switches to SAFEFALSE. | The time value to be configured depends on the safety response time of the functional safety system. The safety response time is the time between arrival of the signal at the input channel and output of the switch-off signal at the device output.Enter a time value according to your risk analysis. |
Non-conformance to safety function requirements
- Verify that the time value set at MonitoringTime corresponds to your risk analysis.
- Be sure that your risk analysis includes an evaluation for incorrectly setting the time value applied to the MonitoringTime input.
- Validate the overall safety-related function with regard to the set MonitoringTime value and thoroughly test the application.
|
Refer to the topic "MonitoringTime" for details.
S_StartReset
Short description | Value |
State-controlled input for specifying the
start-up inhibit after the Sicherheitssteuerung has been started up or the function block has been activated.An active
start-up inhibit must be removed manually by means of a positive signal edge at the Reset input. A deactivated
start-up inhibit causes the S_SafetyActive output to switch to SAFETRUE automatically when the function block is activated and the safety-related function is not requested.Data type: SAFEBOOL Initial value: SAFEFALSE |
-
SAFEFALSE: With
start-up inhibit
-
SAFETRUE: Without
start-up inhibit
|
Non-conformance to safety function requirements
- Be sure that your risk analysis includes an evaluation if the start-up inhibit is deactivated (S_StartReset = SAFETRUE).
- Observe the regulations given by relevant sector standards regarding the start-up inhibit.
- Verify that a suitable start-up inhibit is in place at another location or using other means if the start-up inhibit is deactivated by setting S_StartReset = SAFETRUE.
|
Refer to the topic "S_StartReset" for details.
Reset
Short description | Value |
Edge-triggered input for the reset signal:
- Resetting error messages when the cause of the error is no longer present.
- Manual resetting of an active start-up inhibit or restart inhibit. (Both inhibits are mandatory and cannot be deactivated.)
Data type: BOOL Initial value: FALSE
Hinweis
Resetting does not occur with a negative (falling) edge, as specified by standard EN ISO 13849-1, but with a positive (rising) edge. To implement the reset with a falling edge (with regard to the mandatory acceptance procedure), use the safety-related function block SF_Reset. |
|
-
FALSE: Reset is not requested
- Edge FALSE > TRUE: Reset is requested
|
If the safety-related function is no longer requested (S_OpMode = SAFETRUE) before or during the rising signal edge at the Reset input (for resetting errors), this can signal to the system/machine that a request for the safety-related function is no longer present. This can lead to a risk, for example with the machine/system starting up immediately.
Unintended start-up
- Include in your risk analysis the impact of the reset by means of a positive signal edge at the Reset input.
- Make certain that appropriate procedures and measures (according to applicable sector standards) have been established to help avoid hazardous situations when resetting.
- Do not enter the zone of operation when resetting.
- Ensure that no other persons can access the zone of operation when resetting.
- Use appropriate safety interlocks where personnel and/or equipment hazards exist.
|
Refer to the topic "Reset" for details.
|
Outputs
| Ready
Short description | Value |
Output for signaling "Function block activated/not activated".Data type: BOOL |
-
FALSE: Function block is not activated (Activate = FALSE) and all outputs of the function block are switched to FALSE/SAFEFALSE.
-
TRUE: Function block is activated (Activate = TRUE) and the output parameters represent the state of the safety-related function.
|
Refer to the topic "Ready" for details.
S_SafetyActive
Short description | Value |
Output for confirming the correct feedback from the connected safety-related periphery.Data type: SAFEBOOL |
-
SAFEFALSE: No confirmation of the defined safe state.
The feedback of the connected safety-related periphery about correct execution of the requested safety-related function is not present at the S_Acknowledge input.
-
SAFETRUE: Confirmation of the defined safe state.
The feedback of the connected safety-related periphery about correct execution of the requested safety-related function within the MonitoringTime is present at the S_Acknowledge input.
Hinweis
The safety-related periphery controls the defined safe state autonomously and independent of the function block. |
|
Refer to the topic "S_SafetyActive" for details.
S_SafetyRequest
Short description | Value |
Output for the request of the connected safety-related periphery to execute a safety-related function.Data type: SAFEBOOL |
-
SAFEFALSE: Safety-related function requested
-
SAFETRUE: Safety-related function not requested
|
Refer to the topic "S_SafetyRequest" for details.
SafetyDemand
Short description | Value |
Output for signaling "safety-related function requested". This output displays whether the safety chain is interrupted and as a result, the attention of the operator is required. Data type: BOOL |
-
FALSE: Safety-related function is not requested.
-
TRUE: The safety-related function is requested.
|
Refer to the topic "SafetyDemand" for details.
ResetRequest
Short description | Value |
Output for signaling "reset is required". This output indicates whether a reset by the operator is required. Data type: BOOL |
-
FALSE: No reset required.
-
TRUE: A reset is required:
- to remove an active start-up or restart inhibit (if available for this function block)
-
or to reset an error.
|
Refer to the topic "ResetRequest" for details.
Error
Short description | Value |
Output for error message.Data type: BOOL |
-
FALSE: No error is present.
-
TRUE: The function block has detected an error. As a consequence, the S_SafetyActive and S_SafetyRequest outputs switch to SAFEFALSE.
|
Refer to the topic "Error" for details.
DiagCode
Short description | Value |
Output for diagnostic message.Data type: WORD | Diagnostic message of the function block. The possible values are listed and described in the topic "Diagnostic codes". |
Refer to the topic "DiagCode" for details.
|
Detailed information | Signal sequence diagram
This diagram refers to a typical signal sequence, in which the request of a safety-related function is supported.
The incoming request of a safety-related function by a SAFEFALSE signal at input S_OpMode controls the S_SafetyRequest output directly and without additional dependencies for a request for the safety-related function at the connected safety-related periphery. In the example shown, two requests for the safety-related function occur. Consequently, the time monitoring between the request of a safety-related function and the confirmation message from the safety-related periphery is started twice.
During the first time monitoring, feedback occurs through S_Acknowledge = SAFETRUE within the time parameterized at MonitoringTime, and the S_SafetyActive enable output switches to SAFETRUE (phases 5 and 6 in the diagram).
In the second case, the parameterized time value is exceeded. The function block then detects an error (Error = TRUE) and S_SafetyActive = SAFEFALSE signals that the safety-related periphery is not executing the requested safety-related function (phases 9 to 11 in the diagram).
Application example
This example shows the exemplary use of the safety-related SF_SafetyRequest function block in case of request and feedback of the safety-related function "safely limited speed" (SLS) of a safety-related drive.
The function block is perpetually activated by the TRUE constant at the Activate input. Reset button S1 is connected to the input 1.1 of the standard input device DI 1.
The relevant inputs and outputs are connected as follows:
- The S_OpMode input of the SF_SafetyRequest function block is directly connected to the S_Mode0Sel enable signal of the upstream SF_ModeSelector function block. The request for the safety-related function (of the evaluated mode selector switch) is consequently the selection of the operating mode 0. In our example this is the commissioning or maintenance mode in which the drive is operated with safely limited speed. (See digit (1) in the graphic below.)
- The S_SafetyRequest output is connected to the global I/O variable SReq_SafePerph, which in turn is assigned to the output 1.1 of the safety-related output device PSDO 1 (see (2) in the graphic below). The safety-related drive module is connected to the output terminals 1.1 and 2.1 using two channels here.
- The feedback signal for confirming the selected operating mode of the safety-related drive is connected as two-channel signal to the inputs 1.1 and 2.1 of the safety-related input device PSDI 1. The signal evaluated for equivalence by the safety-related input device is assigned to the global I/O variable SafePerph_Feedb and connected to the S_Acknowledge input of the SF_SafetyRequest function block for evaluation ((3) in the graphic).
- The S_SafetyActive enable output is connected to the S_SafetyActive input of the SF_EnableSwitch function block (see (4)). If the requested safely limited speed is confirmed by the safety-related drive at the S_Acknowledge input within the monitoring time specified at MonitoringTime, the S_SafetyActive enable output switches to SAFETRUE and thus signals the defined safe mode to the subsequent SF_EnableSwitch function block.
Function block instantiation
The IEC 61131-3 standard defines function block instantiation. Instantiation means, a function block is defined once and can be used (instantiated) several times. This applies to all standard and safety-related FBs (local POUs as well as firmware and user library FBs).
Why instantiation? A function block has an internal memory where it stores its own processing data (local variables). As a consequence, the output values calculated by the FB depend on the internally stored values. The same input values applied to an FB instance do not necessarily deliver the same results in another FB instance. Therefore, it is necessary to store the internal data of the FB to a separated memory area each time the function block is processed, i.e., for each FB instance. To uniquely identify each FB instance and to clearly separate its memory area, instance names are used. The instance name of a function block has to be declared in the 'Variables' table of the POU where the FB is going to be used.
The following applies:
- Function blocks can be instantiated in other function blocks or in program POUs. Calling FBs in function POUs is not possible.
- Functions are called without instantiation because they do not have an internal memory.
Safety-related and standard (non-safety-related) code is strictly distinguished in PLCnext Engineer. If a Safety PLC is included in your project, the following applies:
- Safety-related FBs can only be instantiated in safety-related POUs but not in standard (non-safety-related) POUs.
- User-defined standard FBs can only be instantiated in standard POUs. They cannot be called in safety-related POUs.
- Particular standard firmware FBs can be instantiated in both safety-related and standard POUs.
Hinweis
When inserting a standard FB into a safety-related SNOLD network, the rules for implicit type conversion (safety-related to standard) apply. |
Example for the instantiation of a safety-related PLCopen function block
The safety-related PLCopen function block 'SF_EmergencyStop_V2_00' was inserted into the project via a library. It is then available in the 'Programming' category of the COMPONENTS area. There is a folder with the same name as the library that provides the FBs for insertion into the safety-related code. The FB is to be called twice in the code of the safety-related program 'S_Main' to evaluate the status of two safety-related emergency stop command devices. For each FB instance, an instance name is declared in the 'Variables' table of the calling program: EStop_M1 and EStop_M2. The FB instances have been inserted into the code worksheet, each instance with different variables connected to its input and output formal parameters.
Additional information is available in the following sections:
|