Description The Voter block F_2oo3_AI (FB317) of F-Lib V1.3 and F-Lib V1.3 SP1 carries a 2oo3 evaluation of REAL values with discrepancy analysis. It calculates the mean value and the median or maximum and the minimum of the INx inputs depending on the QBADx inputs.
If the discrepancy is greater than the parameterized tolerance DELTA and longer than the parameterized discrepancy time DIS_TIME or if a process signal fails, the cause of the fault must be cleared immediately to restore the availability of the function.
If during plant operation the situation does arise when all three interconnected process values have a discrepancy with each other that is greater than the parameterized tolerance DELTA and longer than the parameterized discrepancy time DIS_TIME, then this state must lead to triggering of the safety function. The Voter block signalizes the discrepancy fault with '1' at the outputs DIS1CH and DISALL. The values at the outputs MED_MIN, MED_MAX and OUT_AVG are no longer defined for this case and are therefore invalid.
In this state the block has a safety-based storage behavior because after a shutdown, the safety function may be put into operation again when all the associated signals are error-free. This means that all three process values must be within the parameterized tolerance DELTA before valid values can once again be output at the above-mentioned outputs and the safety function can be re-enabled.
Instructions The storage behavior of the block for a discrepancy of all three process value inputs can therefore not be recognized as such at the block outputs. The sample solution below shows one possibility of determining this status in the program and providing a signal that can also be evaluated in the subsequent program logic. The discrepancy status is set by an SR flipflop (F_SR_FF) and reset only when the outputs DIS1CH and DISALL of the Voter block (F_2oo3_AI) once again have the value '0'.
Detailed information about this block is available in the manual here: Link
Where can you download the F FBs for the Mobile Panel 277F IWLAN for the Safety option of STEP 7 V5.5 and STEP 7 Professional V11?
More information about how to use the F FBs is available in the manual in Entry ID: 31255853.
"SIMATIC HMI Fail-safe Operation of the Mobile Panel 277F IWLAN > Configuration > S7 Distributed Safety > Use of the F-FBs".
Description The F Systems library does not contain the Emergency Stop block for stop categories 0 and 1. However, this can be created from separate blocks of the Fail Safe library. Fig. 01 shows such a configuration for stop category 1.
Fig. 01: Emergency Stop for stop category 1
In the case of a stop category 1 emergency stop, the "Stop1" emergency stop button is connected via channel driver block "F_CH_DI". This is directed to an AND operation "F_AND4" to which other input drivers can be connected. The RS flip-flop "F_RS_FF" is reset via the negated output of the AND operation.
The acknowledge signal "Quit" is also read in with a channel driver block "F_CH_DI" and interconnected via an edge evaluation "F_R_TRIG" to the set input of the RS flip-flop. The Reset input has priority.
The output signal of the flip-flop is interconnected to the timer block "F_TOF" that switches off the signal with a time delay. The output signal of the time is now directed to another AND operation "F_AND4" to which operational switching can also be connected. The output is interconnected to the output driver "F_CH_DO". These then control the two emergency stop contactors K1 and K2.
The configuration and function are comparable in the case of a stop category 0 emergency stop. Only there is no timer block "F_TOF", so that the output of the flip-flop is wired directly to the "F_AND4" block.
In order to ensure error-free operation of the fail-safe blocks, it is essential to have correct and complete connection of the blocks. More information on this is available in the programming and operating manual "SIMATIC Industrial Software, S7 F/FH Systems - Configuring and Programming" in Entry ID 2201072.
Why should you close opened faceplates for a change of user (log on/off)?
Description: Users often configure faceplates such that the user currently logged on is stored. For example, the user name can be stored in the "Text" property of an object of the "Static Text" type. Depending on how a faceplate is configured, it might happen that the stored user rights are not updated when there is a change of user. Under certain circumstances this might mean that unauthorized switching actions are executed or on the other hand that switching actions cannot be executed due to lack of user rights.
Faceplates should be closed after a change of user and then reopened.
Do not store the user currently logged on. For each operator action, always run a new direct query of the user currently logged on.
This behavior occurs, for example, with the Safety Matrix faceplate.
If you use the Basic Process Control option (e.g. when using PCS 7 or the OS Project Editor), faceplates are closed by default when there is a change of user. Detailed information on this behavior and on authorization checks is available in Entry ID 16626380.
In the case of Standard WinCC, you must manually configure faceplate administration (opening and closing of picture windows). Automatic closing of opened picture windows upon logging on/off can be implemented with a global script action, for example, which is run upon change of the "@CurrentUser" tag.
The following figure shows the configuration of a C action that is run upon a change of user. Here, the picture defined in the action is reloaded as Start picture. If the static value of the "Display" property of possible picture windows has the value "False", then the picture windows are closed upon change of user.
Alternatively, by script you can query the authorization levels configured in the WinCC User Administrator through appropriate ODK functions. Entry ID 27068495 shows how to use the ODK function "PWRTCheckPermission()" to query an authorization level in the script.
What should you watch out for in large projects if you are using F module types?
Description If the amount of F module parameters *.PAR_ID in a safety program exceeds the limit of 65535 and a part of the PAR_IDs is used for F module types, the overall signature of the safety program in the printout footer and in the program information part might differ. It might also happen that the safety mode can no longer be enabled after a delta load of the safety program.
When should you expect this behavior?
You should expect this behavior if all the following conditions apply:
Safety program created with F systems V5.2 or V6.0
Safety program contains F module types
Limit of 65535 PAR_IDs exceeded
Changes in the program incorporated with delta load
How can you prevent this behavior?
You can prevent this behavior by not exceeding the limit of 65535 PAR_IDs in your project. You can reduce the amount of PAR_IDs by:
Deleting F modules and F module types that are not required from the safety program
Reducing the amount of unused inputs and outputs to F module types (such as by creating a F_OR8 instead of a F_OR16)
Dividing the safety program across several F-CPUs.
You can determine the amount of PAR_IDs by using "S7FPIdInfo.exe".
Use of "S7FPIdInfo.exe" is intuitive. Press the "Search" button to select the appropriate S7 program. Alternatively, you can drag the S7 program from the SIMATIC Manager to the "Search" button. The count procedure begins when you press the "Start" button. The amount of PAR_IDs of the S7 program is given under "Total". Select the relevant S7 program via the "Search" button again if you want to carry out more Par_ID count procedures.
Validity The "S7FPIdInfo.exe" tool is only to be used in connection with F Systems V5.2 SP4 or V6.0.
Description: The non-fail-safe output V_MOD of the F channel drivers F_CH_AI and F_PA_AI and the values RAW_VALUE and V_MOD from the AL_STATE structure of the F_CH_AI do not behave as described in the programming and operating manual "Configuring and Programming S7 F/FH Systems, Edition 07/2007" and in the associated Online Help. To achieve the behavior described for V_MOD and AL_STATE , you must add another block between the output V_MOD of the F channel driver and the evaluating blocks. These changes are not part of the safety program.
This FAQ cannot be applied in block types.
Procedure First, you must dearchive the "Support_zip" library attached to this FAQ.
There are 2 blocks available in the attached library for using F_CH_AI. CH_V_MOD (FC) simply provides the updated output V_MOD. CH_V_AL (FB) provides the updated output V_MOD and AL_STATE.
Copy the relevant blocks from the attached library into the block container of your S7 program. Change the FC/FB numbers if necessary.
Place a CH_V_MOD or CH_V_AL next to each F_CH_AI whose V_MOD or AL_STATE output you are evaluating.
Connect the output V_MOD of the F_CH_AI to the input IN of the block concerned.
Use the V_MOD or AL_STATE outputs required of this block for the evaluation.
The following figure shows how CH_V_MOD is used in the CFC.
The following figure shows how CH_V_AL is used in the CFC.
Place the instance of CH_V_MOD or CH_V_AL in the runtime sequence each time directly in front of the first evaluating block (in front of MEAS_MON in the present example).
Copy the PA_V_MOD block from the attached library into the block container of your S7 program. Change the FC number if necessary.
Place a PA_V_MOD next to each F_PA_AI whose V_MOD output you are evaluating.
Connect the output V_MOD of the F_PA_AI to the input IN of the PA_V_MOD.
Only use the V_MOD output of the PA_V_MOD for the evaluation.
Place the instance of the PA_V_MOD in the runtime sequence each time directly in front of the first evaluating block (in front of the MEAS_MON in the present example).
Instructions: In critical processes in which the fail-safe system SIMATIC F is used, it is often necessary to acquire and accumulate volumes error-free. The following document demonstrates possible solutions for this at program level.