Replicating AB Test Edits in Siemens STEP 7 and TIA Portal

Overview: The Test-Edit Gap Between Allen-Bradley and Siemens

Allen-Bradley programmers using RSLogix 500, RSLogix 5000, or Studio 5000 Logix Designer rely on the Test Edits function to assemble pending rung modifications in a buffer, accept or cancel the buffer as a single transaction, and revert a running program to its prior accept-state if the new logic misbehaves. The buffer never touches the running logic until the engineer presses Test (or Accept in Studio 5000), and a single keystroke (typically Cancel / Undo Test) discards the pending edits and restores the previously accepted program.

Siemens STEP 7 (Classic and TIA Portal) does not provide that transactional buffer. Online modifications are written into the load image of the CPU at the moment they are confirmed in the editor. Once committed, the prior logic is gone from the running controller unless you took deliberate steps to preserve it. Engineers crossing over from Allen-Bradley to Siemens therefore need an explicit rollback discipline that mimics the RSLogix behavior.

This reference consolidates the field-proven techniques discussed in cross-platform migration work, the official Siemens documentation for online testing, and the recovery strategies that compensate for the missing transactional buffer. The recommended primary technique is the parallel branch with a test marker bit; supporting techniques cover rung comment-out, STL source comment backup, OB121 syntax-error safety, and leveraging the offline project as a permanent rollback image.

Allen-Bradley Test Edit Behavior Reference

Before building a Siemens equivalent, it is useful to pin down exactly what the AB feature guarantees so the engineering intent can be reproduced:

No Siemens tool supplies all of these properties simultaneously. The techniques in this document each reproduce a subset, and combining them yields an effective workflow that approaches the same operational safety.

STEP 7 Online Edit Constraints and Failure Modes

STEP 7 Classic (S7-300 / S7-400) and TIA Portal (S7-1200 / S7-1500) both allow online editing, but the safety guarantees differ from AB:

• Online editing without CPU stop is supported on S7-300/400 (firmware-dependent) and S7-1200/1500 when the change is structurally compatible (no instance-DB regeneration, no static instance changes, no OB / FB / FC interface change).
• Syntax errors in the edit can force the CPU into STOP. STEP 7 does not have RSLogix's pre-acceptance parse-and-validate loop that rejects obvious syntactic problems before they reach the controller.
• Auto-save prompts: when an online block window is closed, STEP 7 may prompt to save the change back to the offline project. Accepting that prompt overwrites the only rollback copy.
• Memory-load limit: every online download consumes load memory and, on S7-300/400, may require a RAM-to-Flash transfer that halts the CPU briefly.

These constraints motivate the strategies below. They are listed in order of how closely they emulate the AB transactional behavior, and in order of how aggressively they should be reviewed before deployment on a live process.

Strategy 1: Parallel Branch With Test Marker Bit

This is the recommended primary technique. It mirrors the AB technique of duplicating a rung, gating the new logic with a permissive bit, and toggling that bit live to roll forward or roll back without further downloads.

Construction (STEP 7 LAD, S7-300/400 or TIA Portal):

Network 1 (Original)
     |    A    "Input_Start"
     |    =    "Output_Run"

Network 2 (Test copy, gated)
     |    A    "M_Test_Enable"   // M0.0 in STEP 7 Classic, %M0.0 in TIA
     |    A    "Input_Start_Test"
     |    S    "Output_Run"

// To roll back, clear M0.0 from the HMI, watch table, or a separate rung.

Key engineering considerations:

• The marker bit must be a plain merker (M) in STEP 7 Classic — never a retentive marker (MW / MD) unless you explicitly want the test state to survive a CPU restart.
• In TIA Portal, the equivalent tag is %M0.0 in a standard global PLC tags table.
• The parallel network must use sticky (S) / reset (R) coils for any output that latches state, so that toggling the test bit off does not leave the output in an indeterminate state.
• Both networks should be disabled from the HMI / SCADA in tandem by a single test-mode indicator tag so the operator sees when test logic is active.

The rollback is a single bit write — no download, no rebuild, no scan-time impact beyond the disabled branch.

Strategy 2: Comment Out the Original Rung

If the rung is structurally simple and no duplicate exists, the next-cleanest technique is to gate the original logic behind a normally-closed contact of a marker bit, write the new logic in parallel, and toggle the marker to switch.

Network 1 (Original, gated)
     |    AN   "M_Test_Enable"  // NC contact in series
     |    A    "Input_Start"
     |    =    "Output_Run"

Network 2 (New logic, active when test bit is set)
     |    A    "M_Test_Enable"
     |    A    "Input_Start_Test"
     |    =    "Output_Run"

Returning to the original program is a single bit operation. To hard-remove the test logic later, simply delete Network 2 and remove the NC contact from Network 1.

Strategy 3: STL Source Comment Backup

A technique used heavily in the field for narrow, one-off edits is to switch the editor view to STL, copy the original code block, and paste it into the rung's comment field before downloading the replacement. The comment is treated as text by the compiler and travels untouched with the offline project.

Procedure:

1. Open the affected FC / FB and switch the language selector to STL (in TIA Portal: View > STL).
2. Select the entire network in STL and Copy (Ctrl+C).
3. Paste the STL text into the network comment pane (the comment field anchored to each rung).
4. Replace the network body with the new logic.
5. Download the modified FC / FB to the CPU.
6. If the new logic faults, open the network comment, copy the STL text back into the network body, recompile, and re-download.

This approach is cheap and explicit, but it does not protect against loss of the offline project — treat the STL backup as ephemeral and export the FC / FB to a source file for durable recovery.

Strategy 4: OB121 as Syntax-Error Safety Net

A widely adopted precaution is to install OB121 in the CPU before doing the first round of online edits. OB121 is the Siemens priority class for syntax errors in the user program (SYNTAX_FAULT); without OB121 loaded, a syntax error generated by a typo in an edit throws the CPU into STOP. With OB121 present, the syntax error is logged and execution continues with the previous instruction.

Installation in STEP 7 Classic:

1. Open the project in SIMATIC Manager.
2. Right-click the Blocks folder in the S7 program and choose Insert New Object > Organization Block.
3. Select OB121, accept the default properties, and confirm.
4. Inside OB121, place a single line in OB1-style code so that it is non-empty, for example a NOP 0 instruction.
5. Download OB121 to the CPU.

Installation in TIA Portal:

1. In the project tree, expand Program blocks.
2. Double-click Add new block, choose Organization block, set type to OB121 — Syntax fault.
3. Inside OB121, drop a single Empty box with no logic, or write NOP in a tiny STL segment.
4. Compile and download to the device.

Strategy 5: Offline Project as Online Rollback Source

STEP 7 displays the online view and the offline view side-by-side in the project tree; each view lists the blocks that the CPU is currently running and the blocks that are saved in the offline project. The classic migration workflow is to:

1. Open the function to be edited in the online view of the project tree.
2. Modify the block directly online. Accept and download the change.
3. When prompted to save the modified block to the offline project, decline the save prompt. Do not accept, otherwise the offline project is overwritten with the in-flight edit and the rollback copy is lost.
4. To roll back: open the same FC / FB in the offline view of the project tree (it still contains the last good accepted version), copy it, and download it to the CPU.

This is a direct analog of the AB Cancel action: pressing Cancel in RSLogix restores the previously accepted rungs; here the previously accepted FC/FB is held in the offline project until you actively overwrite it.

Project hygiene that supports this strategy:

• Use a version-control system (Subversion, Git, TIA Portal multi-master, or external archive of the S7 archive) to snapshot the offline project immediately before each test-edit campaign.
• Disable Auto Save in the editor options so that the local cache does not silently overwrite the offline project.
• Treat the online view strictly as a temporary window into the live load image; never let it become the canonical source.

TIA Portal Test Workflow (V20)

The current TIA Portal documentation defines online testing in terms of program status monitoring rather than transactional edits. The official Siemens online help for V20 walks the engineer through opening a block, switching program status on or off, and stepping through tag states with breakpoints.

Procedure mirrored from the Siemens TIA Portal V20 documentation (Testing the user program » Switching test with program status on/off):

1. Open the project for the target S7-1200 / S7-1500 station.
2. Go online with the device (Online > Go online).
3. In the project tree, right-click the block you want to monitor and choose Open online. The online copy appears in a new editor tab.
4. In the toolbar, click Monitoring on/off (the eyeglasses icon). TIA Portal overlays live tag values and RLO states on the ladder / FBD / STL network.
5. Right-click any tag in the monitored network to display forced values, modify the tag, or set breakpoints.
6. When you have validated the change, use Compile > Download to device to write the new logic into the load image.

The TIA Portal user-program testing overview is the entry point for the full procedural list, including sequence-of-operations watch, trace, and forced-value handling, all of which complement — but do not replace — the rollback discipline above.

STEP 7 Professional Type Version Editing (V14.0 and Later)

For projects built on STEP 7 Professional V14.0 and onwards (TIA Portal), the type / instance model adds a different dimension to test-edit safety: editing an FB type once and propagating the change to every instance. The official Siemens documentation (Editing a test version of a type — STEP 7 Professional V14.0) describes how to test an FB type before pushing the change to all instances:

1. Right-click the test version or the instance you want to validate.
2. Select Edit type from the context menu. The block opens in the test version editor.
3. Make the changes in the test version, compile, and download to the CPU.
4. Validate in the live system via program status / trace / watch table.
5. Roll back: select Discard test version on the instance — the test FB is removed and production instances are unaffected.
6. Accept: select Release test version. The change is published to every instance of the type.

The type-test workflow is the closest Siemens equivalent to the RSLogix transactional edit buffer, restricted to FBs with the Type / Instance relationship enabled. For FCs, for global tags, and for tag interface changes on non-typed FBs, you still need Strategies 1–5 above.

Strategy Comparison Matrix

Live-Process Safety Checklist

Before applying any of these techniques to a running machine, confirm the following with the controls owner:

• The output tags in scope are not protected by safety hardware (relays, certified e-stops, or Failsafe modules in F-CPU). A test edit on a standard CPU cannot authorize a live I/O changeover on a safety-rated path; all safety logic lives in the F-runtime and follows its own change-management rules.
• The HMI faceplate for the affected output displays the active test-mode marker so operators can see when test logic is engaged.
• A rollback watch-row (or equivalent in the TIA watch table) is pre-built with the relevant bits and tags so the rollback takes one click.
• OB121 is downloaded for the duration of the test-edit campaign and either explicitly retained after acceptance or explicitly removed per plant standard.
• A handheld or remote HMI access route is available to toggle M bits offline, since a logic error that locks the touchscreen or HMI is otherwise unrecoverable without a download.
• For S7-300 / S7-400 firmware prior to V4.x, verify online-without-stop is supported for the type of change; older firmware may require STOP for any modification.

Verification After Accepting the Edit

1. Open the CPU diagnostic buffer (Online > Online & Diagnostics in TIA, PLC > Diagnostic Buffer in Classic) and confirm there are no syntax or I/O faults introduced since the download.
2. In a watch table, force the test marker to FALSE and verify the legacy network returns to controlling the outputs as expected. Restore the marker to TRUE and verify the new network controls as expected.
3. In the same watch table, evaluate the relevant output tags under both states to confirm the rolling behavior matches the documented logic.
4. Take a fresh screenshot of the running program status and archive it against the offline project snapshot.
5. If the test edit survives the verification window (typically the next shift's worth of production), formally accept it by downloading the new logic to the offline project, then archiving the archive (.s7 / .ap14 / .ap20) to source control.
6. If the edit is rejected, roll back via the appropriate strategy, capture the failure mode in the change ticket, and remove the test edit entirely from the offline project so the next engineer starts from the same baseline.

Troubleshooting Quick Reference