PROBLEM:
Problems can arise if several systems each with their own power supply (central rack and distributed connection of expansion units) are connected to a common mains power supply and are switched on/off at the same time. Depending on the different system loads, the system power supplies switch the internal 5V system supplies at different times. This can affect the whole system and must be taken into account when configuring and programming. The effects on the on/off phase are varied and must always be observed separately.

The technical background and proposed solutions are given in the following.

ANSWER:
1. Switch-off phase

There are no problems if the central rack is switched off first (5V system supply) and then the expansion unit. In this case, upon power down the CPU goes into the STOP status and goes back into the RUN mode when the power returns.

If the expansion unit is switched off before the central rack, the CPU can pick up and store another error from the distributed expansion unit. Such an error can be "power fall in expansion unit" (PEU) or "time-out" (QVZ). For safety reasons the SIMATIC S5 system behavior in this case is such that upon return of power, the CPU goes back to the status it was in before power down. Since the CPU had registered an error (PEU or QVZ) just before the power down, it remains in the STOP status. The operator must then, for safety reasons, acknowledge the registered error by switching on the power at the mains source or by restarting the CPU.

Proposed solution:
The PEU signal can be switched off for distributed connections (can be evaluated in programming for CPU 945). In the case of an error, the CPU goes into the STOP status with QVZ and not with PEU. This time-out can be suppressed in programming with the OB23/24. But this has the effect that the CPU no longer recognizes a removed or defective module, for example. We propose the following solution to distinguish between a "true QVZ" and at QVZ caused by power down:

1. Call a function block in the OB23/24
2. Program a time loop in the function block. This time depends on the system and must be derived empirically (we propose 100...500 ms)
3. Program the effect for a "true QVZ" (e.g. STOP)

	L	KT	10.0	Time loop 100 ms
	SI	T1
MARKE	U	T1		Time loop
	SPB	=MARKE
	STP			Reaction to "true QVZ", e.g. STOP
	BE

Notes:

• Time loop -> Time difference between systems on power up
• If necessary, retrigger cycle time
• Reset outputs for time-critical applications

Program description:

If a QVZ (due to power down or "true QVZ") is recognized, the CPU branches into the OB23/24 and the time loop is processed. If the QVZ is due to a power down, the CPU goes into the STOP status during the time loop processing (normal program operation). No further errors are registered and upon return of power the CPU goes back into the RUN operating mode.

If it is a "true QVZ", the next STEP5 operation/sequence is processed once the time loop has elapsed. Here the user can program the reaction to a "true QVZ" (e.g. STOP status).

2. Switch-on phase

On powering up, the CPU registers the entire digital I/O configuration and stores it on a check track. In the cyclic program only the I/O is read and written for updating the process image that is stored on the check track. There are no problems if you power up the expansion unit first and then the central rack.

Proposed solution:
In the case of the AG 115U CPU modules (B version) you have the option of "programmable power-up delay". In this case the I/O configuration is read in only after the power-up delay has elapsed. A delay in the OB21/22 would be ineffective, because the check track has already been read in.

The above proposals solve the problems without any additional hardware costs. If running without errors, the CPU goes into RUN mode as soon as the power returns.