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 (shown in yellow, which is 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. The safety program is also sealed with a safety signature: while it exists, Logix will not let you edit a safety rung. You have to delete the signature first, and the one you generate afterwards carries a new ID and timestamp, which shows that the validated logic was touched. That tamper evidence is part of 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. An ID the controller calculates over the validated safety program, plus a date and time. Safety edits are blocked while it exists, so an unchanged signature shows an auditor that the certified logic is the one that was validated.
✅ 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 and share the chassis and network, much like Siemens' F-CPU. You get one project with two protected worlds inside it.
An engineer edits one rung in the safety task to "quickly test something." What happens to the safety signature?