Resolving RSLogix 500 Online Rung Deletions Safely

RSLogix 500 shows no processor fault, no error message, and no fault light. The new rungs appear to work. Then Ethernet traffic stops, peer PLCs lose shared information, and the process begins failing elsewhere. When you inspect the logic, the rung that called the communications subroutine is gone.

Start here: treat that sequence as an online-edit state problem until you prove otherwise. A rung marked for deletion in another ladder can remain dormant, then become effective when you test later edits and disappear when you assemble them. The cursor position and the ladder currently displayed do not limit those operations.

Recognize the failure pattern

The affected installation used three SLC 500 PLCs exchanging information over Ethernet through a switch. After two rungs were inserted online in one controller, that controller stopped communicating. Reloading the backup restored the missing communications call and normal operation.

Symptom	Likely cause or next check
No fault light or programming error, but communications stop after an online edit	Check whether the communications ladder is still being called. A valid program can run without executing that subroutine.
A rung outside the edited ladder disappears	Search the entire online program for pending or active edits. Testing and assembling are not confined to the displayed ladder.
The fault starts when Test Edits is confirmed	A previously accepted deletion or replacement may have become active.
The rung remains missing after Assemble Edits	The deletion was made permanent when all applicable edits were assembled.
Edits Active appears before new work begins	The processor is already executing inserted logic in place of replaced logic. Do not cancel or untest it blindly.
Edits Exist appears while the machine runs normally	Edits are present but inactive. Inspect them before deciding whether cancellation is safe.

That is not an Ethernet-switch fault merely because Ethernet is the visible casualty. First prove that the PLC is still executing the ladder responsible for communications. If its JSR or equivalent call rung vanished, troubleshoot the edit transaction before replacing network hardware or changing addresses.

Confirm that the requested edit is supported

You can insert ladder rungs while online with RSLogix 500. The act of inserting two rungs is not prohibited. The stated online limitations are adding new program files, adding new data files, and increasing the size of existing data tables.

This decision path applies when the programming computer is online and communicating with the processor while the processor executes logic in REMOTE RUN. Check that operating state before interpreting the edit controls:

1. Confirm that the programming computer is genuinely online with the target processor, not merely viewing a computer-resident file.
2. Confirm that the keyswitch is in the remote position and that the processor is running.
3. Classify the requested change. Adding rungs to an existing ladder is an online-edit task; adding files or enlarging data tables is not.
4. If the change requires an unsupported structural modification, stop the online procedure and plan the required offline change and download under controlled conditions.

Do not spend time trying to reproduce a random processor deletion until you have audited the edit state. A dormant D edit explains why a rung can disappear even though nobody deliberately navigated to that rung during the current job.

Read the edit status before touching logic

Make the edit-status indication your first check every time you connect and your last check before you disconnect. It tells you whether another change is waiting to be tested, is already controlling the machine, or has not been finalized.

• Edits Exist: edits are stored in the program, but they are not currently controlling execution.
• Edits Active: tested edits are currently controlling execution. An inserted rung may be running while its replaced partner remains stored but inactive.
• No edit indication: there should be no pending edit transaction, but still inspect the target call path and save a current backup before modifying a critical system.

If either edit indication appears unexpectedly, stop preparing the new rungs. Record the status and find every marked rung first. Testing your new change can activate an unrelated deletion, and assembling can erase the marked rung from view.

The installation backup loaded after the incident contained no pending edits when the engineers went online again. That clean state allowed the two required rungs to be inserted successfully. It did not prove how the earlier D mark was created; the edit-state mechanism still explains how the deletion became effective during later work.

Find every pending edit online

Use the RSLogix 500 edit-search function across the entire program. Do the authoritative search while online because the processor holds the live edit state. An offline file can show edits saved in that file, but it cannot reveal a newer edit made directly in the processor after that copy was saved.

1. Connect to the correct processor and confirm its identity from the active project and communications path.
2. Read whether the status reports Edits Exist or Edits Active.
3. Run the built-in search for edit zones across every ladder file, not only the file you intend to change.
4. Visit every match and record its ladder file, rung, marker, instructions, and whether its power rails show that version as executing.
5. Trace every affected call rung. Give priority to communications, sequencing, interlocks, mode control, and output-handling subroutines.
6. Repeat the search until you reach the end of the program and can account for every edit marker.

An offline search is useful when reviewing the exact file planned for a download. It is not a substitute for the online search before live editing. Compare the computer-resident copy with the controller state if the program has been open to repeated maintenance changes.

Do not use the displayed rung number as proof of cursor location. Scrolling can move the view while leaving the selection on a rung elsewhere. If the delete key is pressed while that hidden selection remains active, the selected rung can acquire a D marker without disappearing immediately.

Interpret each rung marker before deciding

The marker describes the rung's role in the current edit transaction. Read it together with execution highlighting and the overall edit status.

• I means insert. Before testing, the accepted inserted rung is present but is not yet the executing version. During testing, its highlighted power rails identify it as active.
• R means replace. It is the old partner of an inserted replacement rung. During testing, the unhighlighted rails show that the processor is ignoring this old version.
• D means delete. Before testing, the rung still exists and still executes. Testing the edit removes it from the active scan; assembling removes it permanently from the program.

Accept, Test, and Assemble are separate state transitions:

1. Accept transfers the selected edit into the controller's edit transaction. It does not mean that the new rung is already controlling the machine.
2. Test Edits makes accepted changes operational. On this SLC workflow, it acts across the program rather than only at the cursor or in the ladder on screen.
3. Assemble Edits makes the tested configuration permanent. It removes old R rungs, retains new I rungs without their temporary markers, and permanently removes D rungs.

The word “test” does not mean a syntax-only check. It changes which logic the processor scans. Treat its confirmation dialog as an operating-state change, not a compiler message.

Choose between cancel, untest, and assemble

Start with the displayed status and the highlighted rung version. There is no universally safe “clear all edits” action.

If the screen reports Edits Exist, the marked changes are inactive. The machine is running the pre-edit logic. Inspect every marker and compare it with the approved work scope. If all pending edits are unwanted, canceling them should preserve the logic currently controlling the machine.

If the screen reports Edits Active, the inserted versions are already controlling execution. You have two materially different choices:

• Untest returns execution to the old logic. For a replacement, the old R rung resumes control and the new I rung stops controlling the process.
• Assemble preserves the currently tested behavior and makes it permanent. The old R rung disappears, and the new I rung remains without the edit marker.

Suppose an XIC was replaced by an XIO, the change was accepted and tested, and the machine has been operating with the XIO. Untesting makes the old XIC operational again. Assembling retains the executing XIO. The correct decision comes from the approved control intent and live machine state, not from a desire to clear the message quickly.

If ownership or intent is unknown, preserve evidence. Record the marked rungs, compare them with the latest controlled backup, and obtain an operational decision before changing edit state.

Control the risk before testing

Testing acts as a blanket operation for accepted edits in the SLC program. Assembling is also a blanket operation. You cannot use the cursor to select which accepted edits will test or which tested edits will assemble.

A deleted subroutine call creates a wider hazard than a missing feature. When a ladder stops being scanned, instructions in that ladder stop updating their destinations. An output command or internal state written only there can remain at its last value until some other executing logic writes it. That is why a communications failure may be accompanied by stale commands, incomplete stop behavior, or dependent PLC faults.

1. Place the process in a condition where the edited logic can change state without creating uncontrolled motion or lost coordination.
2. Assign one person to operate RSLogix 500 and one person to watch process and communications status when the system impact warrants it.
3. Confirm that safety and emergency-stop functions do not depend solely on a ladder that could stop scanning.
4. Search for edits and resolve unexplained markers before accepting the new work.
5. Identify the rollback path: untest known new edits when safe, or reload the verified backup under the site's controlled recovery procedure.
6. Watch the called ladders and their critical destinations while transitioning into test.

Changing switch ports, cycling peer PLCs, or rewriting Ethernet configuration wastes time when the controller has simply stopped calling its communications ladder. Check program execution first.

Insert the new rungs without creating stray edits

You can place a new rung by dragging it to the intended location while online. You do not need to double-click the rung below it. Extra selection actions increase the chance of marking the wrong rung or creating more edit zones than expected.

1. Save a backup immediately before the change and identify the running program revision.
2. Search online for all existing edit markers. Resolve or formally accept ownership of each one.
3. Open the target ladder and select the precise insertion point.
4. Drag a new rung into position and enter the required instructions.
5. Review instruction addresses, branch structure, and rung placement before accepting it.
6. Accept only the intended new rung or defined edit set.
7. Search the entire online program again. The matches must correspond exactly to the work just entered.
8. Have the second checker compare every I, R, and D marker with the approved change.
9. Test the edits while watching the affected process, the communications call path, and peer-controller status.
10. If behavior matches the design, assemble the edits. If it does not, choose untest only after evaluating what logic will resume execution.

Keep your hands off Delete, Page Up, and Page Down until you have verified the visible selection. A selection can remain on a rung that has scrolled off screen. The brief software response after a keypress is easy to miss; the resulting D marker is the reliable indication.

Verify the resolving branch

Do not declare success because the processor remains in run and the new rungs appear highlighted. Verify the complete call path and the edit transaction.

1. Search for edit markers after assembly. No unexplained I, R, or D zones should remain.
2. Open the main ladder and confirm that every required JSR, including the communications call, is present and executing when its conditions are true.
3. Open the called communications ladder and confirm that it is being scanned. Observe changing data rather than relying only on the absence of a fault light.
4. Check each peer PLC for restored information exchange and recovery from the secondary problems caused by lost data.
5. Verify critical outputs and internal states that could have retained their last values while a subroutine was not scanned.
6. Save the assembled online program as the new controlled backup and identify it as the post-change version.
7. Before disconnecting, run the edit search once more and read the status area for any remaining edit indication.

If a rung is missing but its deletion has not been assembled, stop and inspect the active edit pair before taking action. If it has been assembled, restore the approved logic from a verified backup or re-enter the reviewed rung under the same controlled test procedure.

Build the operating habit

Online-edit failures recur because pending work survives beyond the moment when it was created. The technician who later presses Test Edits or Assemble Edits becomes the person who activates it, even if the marked rung belongs to another ladder and another maintenance task.

• Search for edits immediately after going online.
• Search again before testing.
• Match every marker to the written change scope.
• Verify the cursor selection before using editing keys.
• Search after assembly.
• Search before going offline.
• Keep a current controller upload or verified backup tied to each completed change.

This habit catches the failure while the D, I, and R markers still explain it. After assembly, the temporary markers disappear, making reconstruction slower.

FAQ