A fail-safe CPU runs two programs side by side: your ordinary machine logic, and a separate, protected safety program with the authority to override it. When an E-stop is hit, the standard program doesn't get a vote — the safety side drops the dangerous output by itself. Here's that split, live.
Left: your standard program wants the saw running whenever the operator presses Run. Right: the safety program (yellow — that's the Siemens convention for F-blocks) gates the actual motor on the E-stop. Press Run, then slam the E-stop: notice the standard logic still "wants" the saw on, but the safe output is cut anyway. The safety world wins.
After an E-stop, releasing it doesn't instantly restart the machine — the safety channel passivates and waits for a deliberate acknowledge (reintegration) before it trusts the signal again. That "you must confirm before restart" step is a safety requirement, not an inconvenience.
The safe E-stop signal travels the same PROFINET cable as everything else — so how can you trust it for SIL 3? PROFIsafe wraps each safe value in an envelope with a sequence number, a watchdog timer and a CRC. If anything looks wrong — a stale number, a late telegram, a bad checksum — the channel assumes the worst and goes to the safe state.
🟨 F-blocks are protected. The safety program has its own runtime group, a collective signature, and is access-protected — you can't casually edit it, and a change is logged and re-verified. That's why it's drawn in yellow.
🤝 Safe & standard coexist. Both run on the one F-CPU and can share data one way (safe → standard is free; standard → safe is restricted). Your machine logic reads safety status but can never weaken it.
A PROFIsafe telegram arrives late — past its F-monitoring time. What does the F-CPU do with that channel?