OmniCore V400XT: Protective Stop Is Safety, Not I/O

The number that matters is A_autoStop = 0. The safety controller is evaluating the automatic-mode protective-stop path as open, so it withholds motor activation. This is electrical continuity and safety-state timing, not motor thermal load or an ordinary PLC command problem.

Working EtherNet/IP communication proves that the Allen-Bradley PLC and robot controller can exchange signals. It does not prove that the independent safety conditions required for motor activation are satisfied. A synchronized safety configuration and green status LED likewise confirm configuration status, not closure of every configured protective-stop input.

Diagnostic approaches and recommendation

Start at the reported safety state and work outward. Changing standard I/O while the safety controller still reports zero only adds variables without changing the interlock that blocks the motors.

Protective-stop signal chain

A protective-stop request normally passes through an external protective device, field wiring, safety input channels, configured safety logic, and the controller's motor-enable permission. Opening any required element prevents the final permission from becoming true. Dual-channel circuits can also remain invalid when both individual conductors appear energized but their states, sequencing, or configured relationship do not agree.

The displayed relationship between A_autoStop and ProtectiveStop2 must be read carefully. Determine whether the displayed zero is a live runtime state, a configured constant, or the evaluated output of safety logic. Toggle the intended source only under controlled conditions while watching the diagnostic value. A live value should follow the source; a fixed or derived value requires tracing the safety configuration upstream.

Automatic mode can expose a safety condition that is not exercised in the same way during another operating mode. The transition to automatic does not cause a motor fault; it applies the configured automatic-mode safety prerequisites and reveals that one of them remains unsatisfied.

Quantities and states to read

Recommended fault-isolation procedure

1. Place the cell in a controlled commissioning state. Prevent unexpected motion and record the active stop indications before changing wiring or configuration.
2. Open the safety controller's live diagnostics and monitor A_autoStop, ProtectiveStop2, and the physical safety inputs that feed them. Separate configured values from runtime values.
3. Use the validated safety project or electrical drawings to identify the source mapped to A_autoStop. Trace all intermediate logic instead of assuming that GS1 or GS2 directly drives it.
4. Operate the intended protective device under controlled conditions and watch each physical channel. If the device changes but the input does not, inspect field power, common reference, contacts, connectors, and conductor continuity. Measure at the documented input terminals using the electrical levels specified for that input hardware.
5. If the physical channels change but A_autoStop remains zero, trace the safety logic for polarity, channel pairing, mode selection, discrepancy state, latch, and reset prerequisites. Correct the wiring or authorized configuration item that disagrees with the validated design.
6. Restore GS1 and GS2 to their designed circuits. A temporary bypass is an isolation aid, not an operating fix.
7. If an authorized safety-configuration change was required, validate it and synchronize the safety configuration again. Confirm the green status indication, then recheck every affected live signal.
8. Clear or reset the protective-stop demand using the configured reset method. Select automatic mode and request motors on only after A_autoStop and the stop-status display show the accepted state.

Verification sequence

1. With all protective devices in their normal state, confirm that the open protective-stop indication is absent before issuing the motor-on command.
2. Request motors on in automatic mode. Verify that motor activation succeeds without changing unrelated EtherNet/IP commands.
3. Operate each protective device individually and confirm that the corresponding live input changes and the protective stop opens. Restore the device and perform the configured reset; motor permission must return only through the intended sequence.
4. Cycle out of and back into automatic mode. Confirm that the controller does not recreate the stop because of a missing mode-dependent input or reset condition.
5. Remove any commissioning jumpers, inspect the final wiring against the drawings, and retain the synchronized safety configuration used for the test.

A green synchronization indication is only one verification point. The functional test must prove the full chain from each field device through the safety evaluation to removal and restoration of motor permission.

Recurring diagnostic pitfalls

• Treating standard communication as safety permission: EtherNet/IP signal exchange can remain healthy while the safety controller independently blocks the motors.
• Bypassing the wrong layer: Jumping GS1 and GS2 has no effect when A_autoStop comes from another input or from derived safety logic.
• Reading configuration as live state: A displayed zero may describe a runtime result, an assigned value, or a logic output. Correlate it with a controlled input transition.
• Ignoring two-channel behavior: One channel may change while its companion remains open, inverted, or out of sequence. Read both channels rather than measuring only the device output.
• Using synchronization as functional proof: A synchronized project can faithfully execute a configuration whose external circuit is still open.
• Leaving test bypasses installed: Bypasses defeat protective functions and invalidate the final functional test. Restore the designed circuit before operation.

FAQ