Studio 5000 Online Edits: Safe Test and Accept Flow

After the edit is accepted, the controller runs the revised logic without a download or PLC stop. On the panel, the fault usually looks less dramatic: an edit marker remains on a rung, the expected change disappears after Unaccept, or a copied routine exists but never executes. Start here: identify whether the logic is pending, being tested, accepted, or merely present outside the task execution path.

Stop Trying the Wrong Fixes

A download is not the first fix for an ordinary rung change. It replaces the controller project and normally requires a planned interruption. Use online edits when the required change is supported online and you can test it safely against the running process.

• Do not import directly as accepted logic. A routine import may offer immediate acceptance, but that bypasses the pending-edit review. Import or paste it as a pending edit, then inspect every reference before testing.
• Do not leave unfinished pending edits in the controller. They create ambiguity for the next engineer and increase the chance of saving an application that no longer clearly represents the running controller.
• Do not press Unaccept when you only want to revise a tested edit. That discards the pending change and restores the previous rung. Press Untest, revise the pending edit, and test it again.
• Do not assume a new routine is executing because it imported successfully. The routine must be reachable through the controller's task, program, and routine execution structure.
• Do not rename or delete a tag without checking external references. An HMI, historian, or other outside system can reference a controller tag even when ladder cross-reference results show no logic use.
• Do not learn the workflow on active production. Test during maintenance, cleaning, or another controlled operating window when a logic mistake cannot immediately stop or damage the process.

Read the Edit State Before Touching the Rung

What you see	Likely cause
The revised rung is visible but its behavior is absent	The edit remains pending or has been untested, so the original rung is running.
The revised behavior is active, but the edit still has test-state markings	The pending rung is being tested live but has not been accepted.
The change vanished after clicking Unaccept	The pending edit was discarded. Start a new online edit and recreate the change.
An imported routine is present but nothing happens	No executed logic calls the routine, or the containing program is not in the required task execution path.
A deleted or renamed tag breaks a display while controller logic remains valid	An HMI, historian, or other external client still uses the old tag reference.
A UDT modification cannot be completed online	The requested change alters the members or member data types of an existing UDT, which is more restricted than creating or importing a type.

The controller does not provide an automatic rung revision history. Once you accept an edit, the revised logic becomes the controller's code. Saving the project preserves the current application file, but it does not turn the controller into a version-control system.

Separate Tag Changes from UDT Structural Changes

Studio 5000 v32.11 can add controller or program tags online without stopping the controller. A tag can be deleted online only after removing controller-logic references and outside-system references. Check ladder logic, HMI displays, alarms, recipes, historian collection, and communications clients before renaming or deleting it.

UDTs need a stricter decision path. Creating or importing a new UDT online is reported as possible, but the reported behavior for creating one directly online is not uniform across installations. Test the exact operation with the target software revision and controller family before scheduling it for production.

Changing an existing UDT is the harder boundary. You can rename existing members in some workflows, but adding members, removing members, or changing a member's data type can require a download and controller stop. A rename is not harmless: external clients using the old member path will not automatically follow it.

If the application was designed with spare UDT members, rename a suitable spare instead of changing the structure. Treat that as a design provision, not a universal workaround. Confirm that the spare has the required data type and that no external client already uses it.

Move Offline Logic into the Running Project

You can copy rungs from an offline project and paste them into the online project. Pasted rungs arrive as pending edits, which gives you a review and test boundary before they affect execution.

You can also export logic from the offline project and import it while online. A whole-routine import is useful when the change contains many related rungs, but an import may offer an option to accept the content immediately. Keep it pending until you have checked tag mapping, routine calls, interlocks, and output ownership.

1. Open the offline source and the verified online project for the running controller.
2. Copy the required rungs, or export the required routine from the offline source.
3. Paste or import the content into the online project as pending logic.
4. Resolve missing tags and verify every reused tag has the same scope, data type, and purpose in the running application.
5. If you imported a new routine, connect it to the intended task, program, and routine call path. Importing the routine alone does not make it execute.
6. Inspect output instructions and state-changing instructions for conflicts with existing logic.
7. Test through a deliberate permissive or test bit where the process design allows it.
8. Accept only after the online behavior matches the intended sequence.
9. Save a project that matches the accepted controller state.

Replacing an existing routine by import carries more risk than adding a new, isolated routine. Test that case away from production because naming collisions, tag handling, and execution references can change the result.

Use the Pending-Test-Accept Cycle Correctly

An online rung edit moves through distinct states. Keep those states separate:

1. Create the pending edit. The controller continues to run the original rung.
2. Review the pending rung. Check branch structure, instruction operands, tag scope, and effects on physical outputs.
3. Test the edit. The changed logic now runs live in the controller. Test mode is not simulation.
4. Untest when revision is required. The controller returns to the original logic while the pending edit remains available.
5. Edit the pending rung again. Make the correction, then repeat the test.
6. Accept the edit. The tested change becomes the controller logic.
7. Save the project. Store the application that represents the accepted state.

You can repeat Test, Untest, revise, and Test while the change remains pending. If you select Unaccept, the controller discards that pending version. There is then nothing left to revise; begin a new edit and recreate it.

Place a test permissive ahead of new logic when that pattern is safe for the machine. Keep it false while accepting the structure, then deliberately enable it under controlled conditions. Never use a test bit to bypass machine protection, safety logic, or required operating interlocks.

Finish or Remove Every Pending Edit

Do not treat the controller as storage for unfinished development. Pending edits left across shifts make it difficult to tell which rung is running, which change was tested, and whether the saved project matches the controller.

Finish the cycle in the same work window:

• Accept edits that passed the operational test.
• Unaccept edits that must not remain.
• Save the accepted state under the site's change-control process.
• Record the purpose, affected routines, new or renamed tags, external dependencies, and test result.

If incomplete code must remain in the application for a controlled reason, isolate its execution with an explicit false permissive and document its location. Comments alone do not prevent execution. A searchable development marker can help locate such logic, but use the site's naming convention rather than a person's name.

Verify the Controller and Project Match

1. Confirm no unintended pending, test, or unaccepted edits remain in other routines.
2. Cross-reference each new, renamed, or deleted tag in controller logic.
3. Check external systems separately. Controller cross-reference results do not prove that an HMI or historian has no dependency.
4. Confirm every imported routine is called from the intended execution path.
5. Exercise both the true and false paths of any new permissive where process conditions allow.
6. Observe the affected sequence through a complete operating cycle, including reset and abnormal-state recovery.
7. Save the online project after acceptance and verify that it represents the running controller.
8. Retain a separately managed pre-change project if the site requires rollback history. The controller itself holds one accepted code state, not a built-in chain of older rung revisions.

If an HMI tag was renamed, test the actual display, command, alarm, and data collection path that uses it. A controller edit can be valid while the supervisory application silently continues to request the obsolete name.

FAQ