RSLogix 500 Rung Comment Migration: Attach Comments to Output Address

Rung comments in an RSLogix 500 project are part of the engineering database, not executable processor logic. That makes them easy to neglect and easy to damage during a cleanup or migration. When comments appear on the wrong rungs after logic is inserted, copied, or reorganized, the right response is to identify the attachment mode, preserve a baseline, and validate the result in an offline copy before changing the production archive.

The attachment choice determines whether documentation follows a rung number or an address associated with the rung.

Understand what is actually moving

RSLogix 500 can associate rung documentation with the file and rung location or with an output address. A location-based comment is useful when a file is intentionally fixed, but edits above that rung can separate the narrative from the logic it was meant to explain. Address attachment can make the comment follow the chosen output address as logic moves. Rockwell’s support note on imported AI500 titles confirms that the software exposes an attachment mode and can convert documentation between output and rung-number association.

Neither mode is universally correct. A rung may have no output instruction, several outputs, an output whose address is reused elsewhere, or an instruction that is moved as part of a larger refactor. An address-based comment can therefore appear on more than one rung, while a rung-number comment can remain in place when its logic moves. Treat attachment as a controlled documentation rule, not as an automatic repair button.

Protect the source before editing

Save the original RSS file read-only and record its checksum, controller name, program revision, and upload date. Export or print the database and rung comments in a form that can be compared later. If the project is being uploaded from a controller, remember that descriptions and comments may not be stored in the SLC processor in the same way as ladder logic. An upload can recover logic while still leaving the project without the correct offline documentation database.

Work on a duplicate file. Choose several test cases: a normal OTE rung, an OTL and OTU pair, a rung with multiple outputs, a rung without an obvious output, and a subroutine that will receive new logic. Record the current file number, rung number, selected anchor address, and comment text for each case.

Select attachment by engineering intent

Use output-address attachment when the output uniquely identifies the function and the rung is likely to move. A motor-run command, sequence-state bit, or alarm latch may provide a durable anchor if that address is governed by a naming standard and is not reused. Keep the comment focused on the purpose, interlocks, and abnormal behavior of the function rather than repeating the symbol description.

Use file-and-rung attachment when the narrative belongs to a location or a section rather than to one address. Examples include transition notes, diagnostic calculations, initialization logic, or a rung containing several related outputs. In those cases, forcing a documentation-only bit into executable logic merely to carry a comment can create maintenance risk. Do not add unused instructions to a running machine only to satisfy a comment convention.

Latch and unlatch pairs deserve special attention because they often share the same address. An address-level description should explain the meaning of the latched state. Rung-specific comments should explain what sets it, what clears it, and which permissives apply. If one shared comment cannot express both actions safely, keep the detailed notes attached by location and use consistent symbols and address descriptions for cross-reference.

Shared addresses require a documentation rule that distinguishes state meaning from the reason each rung acts.

Migrate comments in controlled batches

Begin with one program file, not the entire project. Compare every comment against the original report before changing its attachment. Reassociate only the comments whose intended logic is unambiguous. Insert a temporary test rung above the sample logic in the offline copy, move a sample rung within the file, and copy one sample between files. Observe which comments move and which remain tied to location.

After each batch, search for blank comments, duplicated text, comments attached to unexpected addresses, and output addresses used on multiple rungs. Run cross-references on each anchor. A unique-looking bit can still be written by an unlatch, a move instruction, a file operation, or another routine. If the relationship is uncertain, keep the source comment unchanged and flag it for a controls engineer who knows the machine sequence.

Validate across software and archive boundaries

Open the edited copy with the exact RSLogix 500 version used at the site when possible. Then reopen the saved file and repeat the sample insert-and-move tests. Cross-version conversions and database imports should be treated as migrations in their own right. The official SLC 500 Instruction Set Reference Manual remains the primary source for instruction behavior, but documentation attachment is a software-database behavior and must be verified in the installed RSLogix environment.

Perform a logic comparison to confirm that a documentation-only project change did not alter executable rungs, data table sizes, channel configuration, or processor settings. A comment repair should not become an unreviewed control change. Follow the site’s backup, approval, and download procedures before replacing the master file.

Make the convention maintainable

Add the attachment rule to the programming standard and code-review checklist. Require a current RSS archive with every approved edit, and keep comments synchronized with symbols, electrical drawings, and HMI alarm text. For machines that remain on the SLC platform, align documentation ownership with the broader PLC and PAC systems lifecycle plan and the site’s RSLogix 500 online-editing practices.

The best attachment mode is the one that preserves meaning through the edits the plant actually performs. A verified baseline, explicit selection rules, batch testing, and post-save comparison prevent a cosmetic database problem from becoming a troubleshooting hazard.