The controller can remain in Run while a POINT I/O safety module's RPI is changed online, but the affected I/O connection will not remain operational. The change breaks and rebuilds the connection, and modules in the affected tree may disconnect and reconnect. Treat the operation as planned I/O downtime, not as a transparent online edit. For production equipment, place the process in a defined safe state before touching the setting.
Which RPI change approach fits the risk?
| Approach | Controller state | I/O behavior | Configuration constraints | Use case |
|---|---|---|---|---|
| Direct online edit | Run | The connection drops and is established again; the affected tree may temporarily show disconnected modules | The software displays a danger warning; a safety lock, signature, or ownership state may block the edit | Idle equipment whose unavailable inputs and outputs have been analyzed |
| Inhibit, edit, then restore | Run or another permitted state | The connection is deliberately removed before changing RPI
|
Logic must tolerate the inhibited module, and the process must already be safe | Controlled maintenance when keeping the controller in Run has a justified operational benefit |
| Controlled stop and Program mode | Program | I/O interruption occurs without the application controlling an operating machine | May require an authorized safety unlock, signature removal, or release of module ownership | Recommended production-system method |
Use the controlled-stop approach unless a documented risk assessment specifically permits an inhibited online change. Keeping the CPU in Run provides no continuity for the module connection and does not protect the process from stale, unavailable, or state-changing safety I/O.
Where does the data path stop?
Follow the packet. The controller owns or consumes the safety I/O connection, the configured network and adapter carry the cyclic traffic, and the POINT I/O module supplies or accepts field data. Changing RPI changes the requested cyclic production interval. The existing connection must close because its timing contract no longer matches the requested configuration; a new connection is then opened with the revised setting.
| Path layer | Item to inspect | What the RPI edit affects |
|---|---|---|
| Physical | Field wiring, module seating, adapter link, and intervening switch ports | Nothing should be physically altered, but an existing layer-one defect may prevent reconnection |
| Address/path | Configured adapter or node address and the module's project path | The path normally remains unchanged; loss of the adapter makes every downstream module unavailable |
| Connection | Controller ownership and module connection state | The active connection is withdrawn and recreated |
| Timing |
RPI, safety-task period, and configured timeout-related settings |
The requested update interval changes; the other timing values must still satisfy the safety design |
| Application | Logic response to unavailable inputs and outputs | Fallback behavior executes while data is unavailable |
The disconnect can resemble a reboot in the project tree, but an RPI change is fundamentally a connection reset rather than proof that module power cycled. If several modules share an adapter or ownership path, the visible disturbance can extend beyond the card being edited.
Why can the change affect the safety function?
The controller scan and an I/O connection are separate activities. The CPU can continue executing logic while a safety input or output connection is absent. During that interval, application behavior depends on the configured connection-fault handling and the logic written for unavailable data. Outputs may move to their configured fault behavior, while input data can no longer be treated as a current field measurement.
The RPI and safety-task period are related design inputs, but they are not interchangeable. The RPI controls requested I/O production timing; the task period controls how often safety logic executes. Read both values from the project and recalculate the safety-function response time using the project's approved method. Do not approve a slower RPI merely because the software accepts it.
A locked safety program or active safety signature adds a separate configuration barrier. Changing a protected item may require an authorized unlock and may invalidate or require removal of the signature. Some configurations can also require the controller to release ownership of the module, sometimes described as disowning it, before editing. The programming software's edit dialog and controller status decide which actions apply.
What must be checked before editing?
- Record the current
RPI, safety-task period, module ownership, inhibit state, connection status, and active diagnostics. Save the current validated project through the site's change-control process. - Identify every input and output in the affected module and tree. Trace how the application reacts when each connection becomes unavailable.
- Put the machine or process in its defined safe, idle state. Stop hazardous motion and address stored energy under the site's approved procedure. Do not disable protective functions merely to make the edit convenient.
- Check the physical layer first: module seating, adapter status, network link, switch ports, and field power. A marginal path can turn a short reconnection into a persistent outage.
- Check whether the safety application is locked or signed. Obtain the required authorization before removing protection, and define how the validated signature will be restored.
- Confirm that the proposed RPI remains within the documented timing calculation for every affected safety function. Read missing timeout and reaction-time values from the project or product documentation rather than estimating them.
How should the RPI be changed?
- Hold the process in the verified safe state and block any automatic restart request.
- Place the controller in Program mode for the preferred production method. If an approved plan requires Run mode, inhibit the module first and confirm that the application reports it unavailable as expected.
- Unlock the safety application, remove the safety signature, or release module ownership only when the programming software requires that action. Record every protection state changed.
- Open the module configuration and enter the approved
RPI. Recheck the units and value against the timing calculation before accepting the online-change warning. - Apply the change and monitor the module tree while the connection closes and reopens. Do not command the process while modules are disconnecting.
- If the module was inhibited, remove the inhibit only after its configuration matches the approved project. Confirm that the owner establishes the connection.
- Restore any required safety signature and lock. A changed or missing signature must be resolved before return to service.
If the module does not reconnect, stop changing settings. Compare the configured path and ownership with the baseline, then inspect the adapter, network link, module seating, and diagnostic entries. Restore the recorded RPI if the new timing is the only changed variable and reconnection still fails.
How is the change verified?
| Check | Pass condition |
|---|---|
| Connection | The module and affected tree remain connected without recurring connection faults |
| Configuration | The online RPI matches the approved value and no module remains inhibited |
| Data | Each safety input changes with its field device, and each permitted output follows the validated test sequence |
| Timing | The revised value is included in the approved safety-response calculation |
| Protection | The required safety signature and lock are restored and match the released project |
Test both normal operation and the defined safe response under controlled conditions. Watch the connection throughout the test rather than accepting a single healthy status immediately after reconnection.
Frequently Asked Questions
Why does POINT I/O disconnect when I change the RPI?
The existing cyclic connection was opened with the old RPI. Changing that timing requires the controller to close the connection and establish a new one.
Why does the PLC keep running when safety I/O is offline?
The CPU scan and I/O connections operate independently. Run mode can continue while the application handles unavailable module data according to its fault configuration and logic.
Why do other POINT I/O modules appear to disconnect?
Modules can share an adapter, ownership path, or affected I/O tree. Rebuilding that path can temporarily make more than the edited card appear unavailable.
Why does a safety lock or signature block the RPI edit?
Safety protection restricts configuration changes that could alter validated behavior. Follow authorized change control to unlock or remove the signature only when the software requires it, then restore protection after validation.
How do I verify a POINT I/O safety RPI change?
Confirm the approved online RPI, healthy connection, cleared inhibit state, restored safety protection, and correct operation of every affected channel. Complete the controlled safe-response test and verify that no connection fault returns.