SF_RecipeRead

Help version 1.1 / Issue date: 2023.03
The following description is valid for the function block SF_RecipeRead, Version 1.0z (where z = 0 to 9).

Short Description The SF_RecipeRead FB can read values from the specified data set (file section) in the specified recipe file.
After completing the file read operation, the Done output is set to SAFETRUE and the read values are present at the PayloadRead** outputs (with ** = 00 to 15) of the function block.

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 input" for details.

CommandRead

Short description Value

Edge-triggered input that starts the function block operation.
Data type: SAFEBOOL
Initial value: SAFEFALSE

SAFEFALSE: No read operation is requested.

SAFETRUE: Request to read data from the data set. If the command is executed successfully (which includes a successful validation of the read data), Done switches to SAFETRUE.

Refer to the topic "CommandRead input" for details.

IDRecipeFile

Short description Value

Input for specifying the ID of the recipe file from which data is to be read.
Data type: SAFEINT
Initial value: 0
Value range: 1 to 8 Apply the numeric file ID to this input.

Refer to the topic "IDRecipeFile input" for details.

IDRecipeDataSet

Short description Value

Input for specifying the ID of the data set inside the recipe file from which data is to be read.
Data type: SAFEINT
Valid values: >= 1. The upper limit depends on PLC type.
Initial value: 0 Apply the numeric data set ID (within the file addressed by IDRecipeFile) to this input.

Refer to the topic "IDRecipeDataSet input" for details.

DataSetCRC and FileCRC

Short description Value

Input for specifying the CRC over the data set (file section) and file.
Data type: SAFEDWORD Apply the checksum values to be expected.
The validation of these checksums help to ensure that the correct file and data set is read. These validations are only executed if the corresponding input CheckDataSetCRC and CheckFileCRC (see below) are set to SAFETRUE.

Refer to the topic "DataSetCRC and FileCRC inputs" for details.

CheckDataSetCRC and CheckFileCRC

Short description Value

Input for activating the checksum validation of the

file CRC

data set CRC

Data type: SAFEBOOL

SAFETRUE: Request to validate the respective CRC.

SAFEFALSE: Data read from the recipe file is considered as valid without validating the respective CRC.

Refer to the topic "CheckDataSetCRC and CheckFileCRC inputs" for details.

CheckProjectCRC

Short description Value

Input for activating the checksum validation of the project checksum.
Data type: SAFEBOOL

SAFETRUE: Request to verify the project CRC.

SAFEFALSE: Data read from the recipe file is considered as valid without verifying the CRC.

Refer to the topic "CheckProjectCRC input" for details.

CheckSerialNumber

Short description Value

Input for activating the validation of the serial number of the Safety PLC.
Data type: SAFEBOOL

SAFETRUE: Request to compare the serial number of the Safety PLC with the serial number deposited in the recipe file.

SAFEFALSE: Data read from the recipe file is considered as valid without validating the serial number of the Safety PLC.

Refer to the topic "CheckSerialNumber input" for details.

FV_PayloadRead** (with ** = 0 to 15)

Short description Value

Input for specifying the payload (i.e., failsafe) values (FV).
Data type: SAFEDWORD
Initial value: 0 Connect constants or variables with the values suitable for your safety application.

Refer to the topic "FV_PayloadRead** inputs" for details and observe the hazard message given there.

Outputs Done

Short description Value

Output for signaling "function block processing completed".
Data type: SAFEBOOL

SAFEFALSE:

Function block is not activated (Activate = FALSE), or

the function block processing is still in progress, or

the function block could not complete the processing due to an error.

Refer to...

... the detailed description of the Done output (link below this table).

... the value present at the DiagCode output for details.

SAFETRUE:

Function block is activated (Activate = TRUE) and

the function block has completed its operation successfully.

Refer to the topic "Done output" for details.

PayloadRead** (with ** = 0 to 15)

Short description Value

Outputs for the recipe values.
Data type: SAFEDWORD
Initial value: 0 If Done = SAFETRUE, the values read from the recipe file are present.
If Done = SAFEFALSE, the failsafe values (FV) are present. These values are read from the FV_PayloadRead** inputs.

Refer to the topic "PayloadRead** outputs" 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 topics "DiagCode output" and "Diagnostic codes" for details.

Detailed information 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.

Note
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 recipe function block

The SF_RecipeDeleteDataSet function block was inserted into the project via the RecipeFile 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'. For each FB instance, an instance name is declared in the 'Variables' table of the calling program: SF_RecipeDeleteDataSet1 and SF_RecipeDeleteDataSet2. 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:

Functional description

Fault avoidance

Use Cases, Signal Sequence Diagrams & Application Examples

Diagnostic codes of the FB

CPU load measurement