-

CPU load optimization for a pair of instances for writing and reading of a recipe file

If recipe data is both written and read in one safety-related project, it may be useful to coordinate the activation of the SF_RecipeRead and RecipeWrite instances in order to reduce the CPU load. An inactive instance of a recipe function block causes only half the CPU load as an activated instance.

For example, an instance of SF_RecipeRead could be activated after switching on the Safety PLC and starting the safety application. It then reads recipe values with which the required status of the safety application is established. As soon as the event of a Safety PLC shutdown is announced/detected, it could be deactivated to reduce the CPU load. Then, the SF_RecipeWrite FB could be activated to write recipe data thus saving the status of the safety application in a recipe file.

The following diagram shows an example of a possible signal sequence.

In this example, the safety application is informed about an expected shutdown of the Safety PLC by a variable/signal named SPLCShutdownExpected. This signal is connected ...

If the SF_RecipeRead and SF_RecipeWrite instance are activated alternately (exclusively), the CPU load can be reduced to 2/3 of the value that would occur if both instances were activated permanently.

Note
1) For reasons of clarity, the duration of one Safety PLC cycle is assumed in the signal sequence for each status transition of the FBs. In reality, several cycles may be necessary for this. The time required to completely write recipe data also varies and depends on the amount of data to be written.

0After the startup of the Safety PLC, the SF_RecipeRead function block is immediately activated (Activate = TRUE) as no power down event of the Safety PLC is expected.

As a result, SF_RecipeRead runs through the states 8002 (Prepare), 8004 (Wait for Ready) to 8006 in which it waits for the trigger command at input CommandRead.

Meanwhile, SF_RecipeWrite remains inactive (DiagCode = 0000, Idle).
1Reading recipe data is requested by a rising edge at the CommandRead input of SF_RecipeRead. The FB reads from the addressed data set and then validates the read data.
2SF_RecipeRead has completed its operations successfully. Output Done switches to SAFETRUE and the read recipe values are applied to the PayloadRead** outputs (with ** from 0 to 15).
3The request for the shutdown of the Safety PLC was detected: Signal SPLCShutdownExpected switches to TRUE. This signal change deactivates the SF_RecipeRead instance. The FB enters the Idle state (DiagCode = 0000) and switches its Done output to SAFEFALSE. The PayloadRead** outputs show the failsafe values applied to the FV_PayloadRead** inputs.

Simultaneously, SF_RecipeWrite is activated. The FB runs through the states 8002 (Prepare), 8004 (Wait for Ready) to 8006 in which it waits for the trigger command at input CommandWrite.
4Writing recipe data is requested by a rising edge at the CommandWrite input of SF_RecipeWrite. The FB sends a request to the Safety PLC for writing the data set specified at the IDRecipeDataSet input.
5After writing/updating the data set, the FB waits for the confirmation of the Safety PLC that the file has been written to the file system in the flash memory of the standard controller.

The write operation may take several cycles (which is not considered in this example).
6SF_RecipeWrite reads the newly written data from the RAM and validates that the data set has not been overwritten by another SF_RecipeWrite instance or deleted meanwhile (CRC comparison). Furthermore, the FB validates that the values applied to the PayloadWrite inputs have not been modified.

After the successful validation, output Done switches to SAFETRUE indicating the completion of the FB execution.
7The expected shutdown of the Safety PLC is initiated. Input Activate is switched to FALSE. As a consequence output Done switches back to SAFEFALSE.