RSLogix 500 rung comments look cosmetic until a logic edit shifts an entire file and every note lands on the wrong rung. The distinction that matters is how the comment is attached: to File/Rung versus to an Output Address. File/Rung attachment pins text to a rung number inside a program file. Insert a rung above that location and the comment stays with the old number, orphaning the documentation from the logic it once described. Output Address attachment binds the comment to a specific output instruction address so the text follows the logic when rungs are inserted, deleted, or rearranged.

For any ladder that will be maintained across multiple revisions, prefer Output Address comments on the primary output of the rung. When technicians insert interlocks or branch conditions above existing logic, the explanatory text travels with the OTE, OTL, or other output that defines the rung’s purpose. That behavior is exactly what you want during migration from a dense OEM file into a cleaned plant standard.

Latch pairs and shared comment collisions

OTL and OTU instructions that reference the same bit share one Output Address comment space. If you document the latch rung richly and later add an unlatch rung on the same address, both rungs surface the same comment text. That is not a bug; it is how address-based documentation works. The practical remedies are deliberate. Use the I/O or bit description fields for the shared address-level meaning (“Discharge valve seal-in”), and keep rung-specific narrative on a unique output—often a placeholder bit in a B3 binary file used only for documentation anchors—or accept a short shared comment and put detailed notes in the rung’s HTML/long comment only where your version supports it without splitting.

Placeholder bits such as B3:x dedicated to comment anchors must never be reused for real permissives. Name them clearly in the data table description (for example, “DOC_ONLY_FillSeq”) so future editors do not “clean up” unused bits and destroy the comment map.

Migration procedure

1. Export or print the existing comment report so nothing is lost before retargeting.
2. Identify rungs whose comments are File/Rung attached and that sit in files expected to grow.
3. Re-enter those comments with Output Address attachment on the main output address.
4. For OTL/OTU pairs, decide whether a shared address comment is sufficient or whether a B3 documentation bit should carry the detailed text on one of the rungs.
5. Insert a test rung above a commented rung and confirm the comment follows the output.
6. Save, upload if required by site practice, and archive the .RSS with a version note describing the comment strategy.

Version notes and verification

Comment behavior has been consistent in spirit across widely deployed RSLogix 500 versions, but always confirm attachment type after a cross-version save. Opening an older .RSS in a newer editor and saving can normalize database fields; spot-check a sample of rungs rather than trusting a bulk assumption. Search for empty comment markers after copy-paste between program files; pasted rungs sometimes arrive without the attachment you expected.

Verify by inserting and deleting rungs in a scratch copy of the processor file, then compare comment placement against the output addresses. If a comment remains stuck on rung 12 while the OTE moved to rung 15, it is still File/Rung attached. Fix it before the next production edit window.

Clear documentation reduces mean time to repair on SLC-era machines that still anchor many packaging and materials lines. Treat comment attachment as part of the code standard, alongside symbol naming and cross-references, when you maintain or migrate PLC & PAC systems under RSLogix 500.