A GuardLogix controller runs a normal program and a separate, certified safety task with its own safety tags and the authority to override. The standard logic can ask the robot to run; only the safety task, watching a dual-channel E-stop, decides if it's allowed to. Hit the E-stop and watch who wins.
Left: the standard task wants the robot running whenever the operator presses Run. Right: the safety task (yellow — Rockwell's safety colour) gates the actual drive-enable on a dual-channel E-stop. Press Run, then the E-stop: the standard side still "wants" motion, but the safety output is cut anyway. Safety always wins.
A GuardLogix E-stop needs a deliberate reset after release — it won't auto-restart. And the safety program is sealed with a safety signature: change one safety rung and the signature invalidates, flagging that the validated logic was touched. That tamper-evidence is what makes it certifiable to SIL 3 / PLe.
🟨 Separate safety task & tags. Safety logic, safety I/O and SAFETY-class tags are isolated. Standard logic may read safety status but can never weaken it.
🔏 Safety signature. A cryptographic fingerprint of the validated safety program. Any change invalidates it — proof to an auditor that the certified logic is intact.
✅ Certified instructions. A dedicated set (ESTOP, DCS, SFX…) developed and certified for safety use — you don't roll your own E-stop logic from plain contacts.
🤝 One controller. Standard & safety coexist on the GuardLogix, sharing the chassis and network — like Siemens' F-CPU. One project, two protected worlds.
An engineer edits one rung in the safety task to "quickly test something." What happens to the safety signature?