Fault avoidance
This topic contains the following sections:
- Validation
- Recognition of incorrect/invalid data set deletion operations
- Simultaneous read and "data set delete" operations within one cycle
- Simultaneous write and "data set delete" operations within one cycle
- Plausibility and connection errors
- Sporadically switching or toggling signal levels or impermissible signals
- Machine/system start-up without a function test for safety-related equipment
Validation
Only you, the user, machine builder or system integrator can be aware of all the conditions and factors realized in the design of your application for the machine. Therefore, only you can determine the automation equipment and the related safeties and interlocks which can be properly used, and validate such usage.
|
WARNING
|
| Unintended machine operation Validate the overall safety-related function and thoroughly test the application. |
Recognition of incorrect/invalid data set deletion operations
The function block as well as the Safety PLC implement several verification and validation measures to help prevent malfunctions of the FB (and thus of the entire safety application) or the use of invalid recipe data.
| Possible fault/invalid operation | Consequences to be avoided | Countermeasure by the FB |
|---|---|---|
| Invalid file ID applied to the FB input IDRecipeFile. The ID is not within the valid value range. | Recipe data set (section) cannot be deleted. | The FB verifies every ID applied to the FB inputs. As a result,
|
| Multiple delete requests for the same data set by several instances of the SF_RecipeDeleteDataSet function block. | Data set can only be deleted once. | The first instance that is called deletes the data set and switches its Done output to SAFETRUE.For the other FB instances which are not successful, the following applies:
|
Simultaneous read and "data set delete" operations within one cycle
If an already activated SF_RecipeRead instance cyclically reads recipe data from a data set and a SF_RecipeDeleteDataSet requests the deletion of the same data set at the beginning of a cycle (before the read operation), the following applies: The SF_RecipeRead FB reports an error as it cannot read the already deleted data.
From the point of view of the SF_RecipeDeleteDataSet FB, this scenario is not considered as a fault and is therefore not prevented by the Safety PLC. It is your responsibility as an application developer to ensure that read accesses to and the deletion of recipe data sets are appropriately coordinated in the safety application.
Simultaneous write and "data set delete" operations within one cycle
If a SF_RecipeWrite instance and a SF_RecipeDeleteDataSet instance are called within the same cycle for the same data set, the instance called last completes its operation successful. The instance called first is "overruled" by the second FB and reports an error as it cannot validate its values.
Example: First, an SF_RecipeWrite instance is called and writes its payload values into the data set. Afterwards, an SF_RecipeDeleteDataSet instance is triggered and overwrites the newly written data set with 0-values (thus completing its operation successfully).
This scenario is not considered as a fault and is therefore not prevented by the Safety PLC. It is your responsibility as an application developer to ensure that write accesses to and the deletion of recipe data sets/files are appropriately coordinated in the safety application.
Plausibility and connection errors
Plausibility errors are errors which occur, for example, when a range of values is exceeded or an impermissible connection is made. Such errors are detected and reported either by the function block itself or while the project is being compiled. However, this is not always possible in the case of connection errors.
This means that it is not possible, for example, to automatically verify whether:
- Values or constants within the range of validity at inputs are, in fact, incorrect for the safety-related function executed.
- Inputs and/or outputs are incorrectly connected or are not connected when they should be.
|
WARNING
|
| Unintended machine operation Validate the signals, formulas, variables or constants connected to the input and output formal parameters of the safety-related function block and thoroughly test the application. |
Sporadically switching or toggling signal levels or impermissible signals
If no additional fault avoidance measures are taken, signal levels which switch or toggle sporadically at the state-controlled inputs may cause the signal to trigger a potentially undesirable corresponding action.
Impermissible signals at inputs can lead to an unintended start, prevent a requested action from being executed or cause an error.
These signals may be caused by:
- Programming errors in the application program (user errors).
- Cross circuit, short circuit, and cable break (user errors, wiring errors).
To prevent this, the following measures can be taken, depending on the safety-related function:
- Using options for cross-circuit detection.
- Suitable cabling.
- Verifying the safety-related code in the Code Editor followed by validation of all safety-related networks.
The measures listed above can also be taken in combination in order to help prevent cascading or otherwise difficult to detect errors.
Machine/system start-up without a function test for safety-related equipment
Inoperable or error producing safety-related equipment can only be detected by testing whether it is functioning correctly. The function block does not support function testing.
Possible causes of inoperable or error producing safety-related equipment are:
- Inoperable devices (hardware errors)
- Cross circuit, short circuit, and cable break (user errors, wiring errors)
|
WARNING
|
Unintended machine operation
|