-

Functional description

The safety-related SF_RecipeWrite function block is part of a safety library which provides function blocks for the applicative recipe handling of the Safety PLC.

The SF_RecipeWrite FB can be used to create or modify a recipe file with the values applied to its PayloadWrite inputs.

One function block instance writes one data set in a recipe file. A data set contains 16 SAFEDWORD values (64 bytes of data). See topic "Recipe Files: Background Information and File Structure" for details.

The recipe file is stored in a remanent memory (e.g., SD card) of the higher-level standard controller. General information on recipe files and their structure etc. can be found in the topic "Recipe Files: Background Information and File Structure" in the preface of this library help.

After writing the payload values into the specified data set (section) of the recipe file, the entire file and the written data set are sealed and checksums are calculated. A recipe file consists of several data sets (which are also referred to as sections). The FB calculates a checksum over the entire file (FileCRC) and a checksum over each contained data set (DataSetCRC). The FB writes these checksums into the recipe file together with the serial number of the current Safety PLC and the checksum of the current project.

After completing the file write/seal operation, the Done output is set to SAFETRUE and the calculated CRCs are applied to the outputs DataSetCRC and FileCRC.

Recognition of incorrect/invalid write 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. This includes, for example,

Allowed but potentially unwanted multiple accesses

Other simultaneous accesses by several recipe function blocks may be not considered as an error but should nevertheless either be prevented by structuring the safety application accordingly or, if they are necessary, verified carefully by means of a function test.
Examples for such generally allowed but potentially critical simultaneous accesses are:

Further Info
Refer to the help topic "Fault avoidance" for further details.