Start-up Behaviour of S5-115U - QVZ or PEU with Distributed Interfacing
Why does the CPU possibly not start properly after an automatic restart, but turns to STOP with error message "QVZ" or "PEU"? In USTACK further useful information frequently do not appear.
The system behaviour - the central controller does not automatically start-up (QVZ, PEU) - always occurs, if several systems with an own power supply (central controller and distributed connection of expansion units) are connected to a common voltage supply and if they are switched on and off at the same time.
Due to different load of systems, system's power supply switch the internal 5V system voltage at different times. This has impacts on the overall system and is to be observed during design or programming. In this context impacts during switching-on / off phases are different and thus have to be considered separately.
I. Switching-off Phase
- No problems occur, if the central controller turns dead prior to the expansion unit (5V system voltage). In this case the CPU affected by power failure (NAU) changes to STOP and after recovery of voltage orderly into RUN again.
- In case the expansion unit falls dead prior to the central
controller, the CPU can detect and save an error from the
distributed expansion unit. These errors can be periphery unclear
(PEU) or acknowledgement delay (QVZ). Because of safety reasons the
system behaviour of SIMATIC S5 in this case is such that after
recovery of the power supply the CPU accepts the mode it was in
before power failure (NAU).
For example, the CPU remains in STOP because the CPU has saved an error shortly before the power failure (PEU or QVZ). The recognized error must be acknowledge by the user via an On of the power supply or a restart of the CPU because of safety reasons. It's a system property of the S5-115U family that CPUs turn to STOP, if a OB23/24 is not programmed, or if a STOP is programmed in OB23/24.
The signal PEU can be switched off with distributed interfacings (with CPU 945 evaluable by software). In case of error the CPU turns to STOP not via PEU, but via QVZ. This delay of acknowledgement can be suppressed with software via OB23/24. The disadvantage, however, is that e. g. a drafted or faulty block of the CPU is no longer recognized ("actual QVZ"). To distinguish between an "actual QVZ" and a QVZ as the result of a power failure, we propose the following solution:
- Generate a block and open it within OB 23/24.
- Program a time loop into the block. The length of the loop depends on the plant and must be determined empirically (suggestion: 100...500ms).
- You programm the consequences of an "actual QVZ" behind the time loop (e. g. STOP).
Program Example in Functional Block
|:SP||T x||Trigger timer x with RLO = 0|
|:L||KT 10.0||Time loop = 100msec|
|:SP||T x||Start timer x with RLO = 1|
|:STS||STOP as reaction to "real QVZ"|
- Time loop > time difference between systems during switching off.
- Cyclical time may need retriggering.
- With time critical applications reset outputs.
In case a QVZ (through power failure or "actual QVZ") is recognized, the CPU diverts into OB23/24 and the time loop is processed.
In case of a power failure, the CPU turns to STOP even during processing of the time loop (normal programm processing). No further error is recorded and after recovery of power the CPU changes to RUN.
In case of a "actual QVZ", after termination of the time loop the next STEP 5 operation/sequence is processed.
Here you can programm fully the response with an "actual QVZ" (e. g. STOP state).
II. Switching-on Phase
During switching-on phase, it needs to be oberved that the CPU detects the overall digital set up of the periphery and saves it in a control sector. Within a cyclical program, only the periphery is read and written during an update of that process image, which is recorded in the control sector. No problems occur, if the expansion unit is connected to the supply before the central controller.
With S5-115U central modules (CPUs Version B) there is the possibility of a "programmable start-up delay" (see S5-115U Manual Chapter 2.5.1 Start-up Behaviour). In this case the periphery setup is read after termination of the start-up delay. A delay in OB21/22 would be without effect, since at this point in time the control sector has already been read.
With this suggestions, above mentioned behaviour can be removed without additional expenses of hardware. In the error free mode the CPU moves into RUN, as it should, after power recovery.