Disabling TI555-1106 I/O Scanning in APT Software for Simulation

Overview: Disabling I/O Scanning on the TI555-1106

The Siemens TI555-1106 CPU, part of the legacy SIMATIC TI500 family, exposes an architectural detail that APT (Advanced Programming Technology) programmers often need to exploit during commissioning: the input process image X (discrete) and WX (analog word) are not physical bus locations, they are memory-resident areas inside the CPU. The CPU refreshes these memory areas from input modules during the deterministic I/O scan. When the matching physical modules are absent, the memory retains whatever value user logic last wrote to it.

This technique is most commonly required when an external simulator — typically an Allen-Bradley ControlLogix or CompactLogix, or a Red Lion DA30D Data Station Plus acting as a protocol bridge — writes simulated process values to the TI555 memory map. The engineer wants those simulated values to appear at symbolic input tags X1, WX10, etc., without the I/O scanner overwriting them every cycle, and without having to rewire the production program.

The reference below walks through the entire procedure: validating that no physical input modules occupy the slots of interest, isolating simulation logic inside a dedicated APT UNIT, configuring MATH blocks to copy symbolic memory tags to the now-writable X/WX addresses, sidestepping the APT compiler read-only restriction with the Y/X mnemonic trick, and verifying the result end-to-end through the DA30D bridge.

Prerequisites

• CPU: Siemens TI555-1106 installed in a TI500-series base (4-, 7-, or 14-slot) with input modules removed from the slots whose memory will be written by simulation logic.
• Software: APT version matched to the CPU firmware revision, installed on a Windows host (XP, 7, or 10 with appropriate compatibility flags) with a serial or Ethernet connection to the TI555.
• Project file: An existing APT project (.pc or project equivalent) with at least one previously generated UNIT, or a fresh project skeleton ready for new UNITs.
• Symbol table: Defined symbolic tags for the simulated discrete inputs (e.g. DI_PUMP_RUN) and analog inputs (e.g. AI_TANK_LVL).
• External data source: A Red Lion DA30D Data Station Plus, an Allen-Bradley PLC, or any Modbus/TCP master capable of writing to TI555 V, V., C, X, Y, WX, or WY memory areas. Crimson 3 configuration software is required for DA30D setup.
• Hardware tools: Insulated extraction tool for I/O modules, ESD wrist strap, LOTO lock set, and the original module layout drawing.

TI555-1106 Memory Map Reference

The TI555 CPU exposes the following memory areas to APT programs. Each area is a contiguous block of 16-bit words inside the CPU; understanding the size and access semantics is essential before manipulating any area.

Note the asymmetry above: by convention, X and WX are read-only; by architecture, they are simply shared static RAM that the I/O scanner overwrites each scan. When the physical source of that overwrite (the input card) is removed, write access is restored to user program logic.

TI555 Memory Layout Diagram

The diagram below summarises the logical relationship between the CPU memory areas, the physical I/O modules, and the external simulator's data source. Each box represents a 16-bit word; the arrows represent the source of each value during a normal scan.

Core Principle: Physical I/O Removal Frees the Memory

The TI555-1106 performs a deterministic I/O scan at the start of every program cycle. During this scan the CPU queries each configured base, reads the input modules' data into the X/WX memory areas, and copies Y/WY memory out to the output modules. These memory areas live in the CPU's static RAM.

If the input module physically present at a configured slot is absent, the CPU has no source from which to refresh the corresponding memory area. The bits and words retain their prior values — whether those prior values came from a previous I/O scan, from user program writes during initialization, or from external writes arriving via a protocol converter such as the Red Lion DA30D.

Critically, the input process image is not write-protected by the CPU hardware. APT's compiler marks X/WX as read-only to prevent accidental bus contention and to enforce good engineering practice. Bypassing that protection requires addressing the compiler's syntactic check, which is covered later in this article.

Step 1: Remove Physical Input Modules

1. Power down the TI555 base and follow the site's lockout/tagout (LOTO) procedure before any module removal.
2. Document the slot position and module type of every input card (discrete and analog). Note whether the slot is configured in the CPU's I/O configuration as an input or output slot — this configuration is normally visible from APT's I/O Configuration dialog.
3. For each slot, decide whether the entire slot is required for simulation. If the program logic reads input word 4 but never references slot 5, you may leave slot 5 populated; only the memory range associated with removed modules becomes freely writable.
4. Remove the selected input modules using the appropriate extraction tool. Output modules may remain in place; their associated Y/WY memory is always user-writable.
5. Power the base back up and observe the CPU's I/O fault LEDs. Expected result: an I/O fault indication for each missing module, but the CPU should continue in run mode if the fault-handling configuration permits.
6. From APT's online status screen, confirm that the affected X/WX words now display frozen values or "bad" flags rather than scanned values. After the compiler bypass is in place you should also be able to force-set these addresses from the online editor.

Safety considerations for module removal

• Confirm that no field wiring carries hazardous voltage before extraction. Some TI500 bases use backplane interconnects that remain live even when the CPU is in Stop.
• Mark each removed module with its slot number and install blank filler plates to maintain airflow and EMI shielding.
• If the base contains a redundant power supply, both supplies should be de-energised and locked out.

Step 2: Create a Dedicated TEST UNIT in APT

Rather than mixing simulation logic into a production UNIT, isolate the simulation behavior in a dedicated APT UNIT. This makes compile-time enable/disable straightforward and keeps the simulation mapping co-located.

1. Open the APT project and navigate to the project tree.
2. Right-click the UNITs folder and select New UNIT.
3. Name the UNIT TEST (or another project-specific name; the field report uses TEST by convention).
4. Set the UNIT's execute priority. By default a UNIT executes every scan; for simulation logic this is fine, but a timed or event-driven UNIT may be configured to mimic real I/O update rates.
5. In the Compiler Configuration dialog, locate the new UNIT and verify it can be enabled and disabled independently of the production UNITs.
6. Compile the project. The Compiler Configuration dialog will list which UNITs are included in the build; the TEST UNIT should appear and be independently toggleable.

The toggling mechanism is the key affordance this approach provides. During initial site commissioning, the engineer disables the TEST UNIT and validates the production UNIT against real field wiring. After validation, the engineer enables TEST for operator training, HMI development, and acceptance testing without ever touching the production logic.

UNIT composition guidelines

• Place all MATH blocks performing simulation passes inside the TEST UNIT. Do not declare the symbolic tags inside the UNIT; declare them at project scope so the same tags are visible to production UNITs.
• Avoid placing control logic (interlocks, permissives, shutdown logic) inside TEST — a disabled TEST UNIT would silently bypass that logic. Tests with safety implications must always be performed with TEST enabled and the production UNIT under formal change control.
• Reserve at least one comment block at the top of TEST documenting the audit trail: who created it, what release, which inputs it simulates, and the date of last verification.

Step 3: Assign Symbolic Variables to Internal Memory

Before configuring the MATH blocks, declare the symbolic tags that the external simulator (Red Lion DA30D, AB PLC) will write to. Use V for integer values and V. for floating-point values.

This layer of indirection is intentional: never let the protocol converter write directly into X/WX. Route through V/V. so that scaling, fail-last-value, and sanity checks can be performed inside the TI555 program before the value reaches the input image. This also means the simulator mapping is reusable across projects — only the final pass-through target address changes.

Float alignment rules for V. memory

Each V. address consumes 32 bits and must be aligned to an even 16-bit boundary in the underlying V space. Crimson 3 and the AB PLC mapping must respect this alignment, or float values arrive misread. Recommended practice: assign V. addresses at even indices (V.50, V.52, V.54, ...). The DA30D's Data Mapping view exposes a per-register width selection; choose 32-bit float registers and ensure the start index is an even multiple of 2.

Step 4: Configure MATH Blocks in the TEST UNIT

Within the TEST UNIT, add MATH blocks that copy from V/V. into X/WX. At this point the APT compiler will refuse to accept the assignment because X1 is marked read-only. The workaround is addressed in the next section; first, here is what a corrected MATH block looks like after the workaround has been applied.

(* MATH block 1: scaled analog pass-through *)
SRC := SIM_AI_TANK_LVL_RAW;     (* V.50, written by DA30D *)
DST := WY1;                     (* 32-bit float copied into WY1 *)
(* APT requires same address number on both sides when X/Y     *)
(* rule is invoked; therefore this becomes WX10 via a         *)
(* dedicated swap block, see Step 5                            *)

For discrete passes, the canonical pattern is to set or clear a single bit inside the WY1 word and then write WY1 to its physical target slot (which, being empty, behaves as a write-through to X1):

(* MATH block 2: discrete enable relays *)
IF (SIM_DI_PUMP_RUN AND 16#0001) <> 0 THEN
    WY1 := WY1 OR 16#0001;     (* set bit 0 of WY1 *)
ELSE
    WY1 := WY1 AND 16#FFFE;    (* clear bit 0       *)
END_IF;

IF (SIM_DI_VALVE_OPEN AND 16#0002) <> 0 THEN
    WY1 := WY1 OR 16#0002;     (* set bit 1 *)
ELSE
    WY1 := WY1 AND 16#FFFD;    (* clear bit 1 *)
END_IF;

IF (SIM_DI_REMOTE AND 16#0004) <> 0 THEN
    WY1 := WY1 OR 16#0004;     (* set bit 2 *)
ELSE
    WY1 := WY1 AND 16#FFFB;    (* clear bit 2 *)
END_IF;

Edge-case MATH pattern: scaling floats into integer WX words

Some field installations require that the simulated analog value reach a 16-bit integer WX word (for example, when the production logic performs integer comparisons such as IF WX10 > 8000). Use a scaling MATH block with explicit range clamping:

(* MATH block 3: float-to-integer scale *)
TEMP_INT := REAL_TO_INT(SIM_AI_TANK_LVL_RAW * 276.48);   (* 0–100% into 0–27648 raw *)
IF TEMP_INT < 0 THEN TEMP_INT := 0; END_IF;
IF TEMP_INT > 27648 THEN TEMP_INT := 27648; END_IF;
WY1 := TEMP_INT;        (* write to WY1 / WX10 via the address trick *)

Step 5: The Compiler Address Trick (Y vs X)

The APT compiler performs a syntactic check during build: any write to Xn or WXn generates an error such as "X1 is read only". The compiler's address validation does not distinguish between the X mnemonic and the Y mnemonic when only the address number is concerned — both X1 and Y1 resolve to memory word 1.

Because of the address-number uniqueness rule (X and Y cannot share the same number in the program at the same time), a write of the form Y1 := Y1 compiles cleanly. The runtime behavior of Y1, however, depends on whether a physical output card sits in slot 1.

• If slot 1 holds an input card (or no card): the memory at word 1 is the input image. Writing to Y1 actually writes into the same RAM location the input scanner would use. Because no scanner exists, the value persists and is read by downstream logic as if it were a real input.
• If slot 1 holds an output card: the I/O scan overwrites Y1 every cycle, and the MATH-block write is overwritten. The technique will not work in this configuration — this is one of the diagnostic signals used in the troubleshooting matrix below.

The same logic applies to the analog word space: writing to WYn is allowed by the compiler, and if no analog output module occupies that slot, the RAM at WXn/WYn retains the user-written value.

Compiler strategy: shadow addressing

An alternative to the mnemonic-trick is to keep production logic reading from X/WX and have the simulation layer write to addresses that the production logic has been edited to consume. This requires editing the production program and is therefore more invasive than the Y/X trick, but it eliminates the unusual compiler construct entirely. Choose one approach per project and document it.

Step 6: Wire Up the Red Lion DA30D Protocol Bridge

The Red Lion DA30D Data Station Plus is typically configured with two drivers: one targeting the Allen-Bradley PLC (DF1, EtherNet/IP, or Modbus/TCP depending on platform), and one targeting the TI555 (NITP, MODBUS, or Siemens legacy protocol). The DA30D performs the simulated-process-image mapping between the two.

1. In Crimson 3 (Red Lion configuration software), add the Allen-Bradley driver and define an internal tag for each simulated process variable (e.g. SIM_PUMP_RUN mapped to AB tag SimInput.PumpRun).
2. Add the Siemens legacy / MODBUS driver. Configure the data map so each internal tag is written to the corresponding V or V. address in the TI555 (e.g. SIM_DI_PUMP_RUN → V100).
3. For outputs, route from TI555 Y/WY addresses back to AB tags so the operator on the simulator HMI sees the responses of the TI555 logic.
4. Save the Crimson configuration to the DA30D and cycle power to ensure the new project loads.
5. Use Crimson 3's Diagnostic → Communications → Statistics view to verify request counts and error counts on both drivers. A non-zero error count indicates a mapping mismatch (commonly a wrong register width or byte order).

Byte-order and scaling between platforms

The TI555 stores 16-bit words in big-endian format. The AB ControlLogix and CompactLogix store INT tags in little-endian format. The DA30D performs byte swapping only when its driver configuration specifies Word Swap; if you observe that V100 in the TI555 equals AB tag value 0x1234 but logs as 0x3412 on the AB side, enable Word Swap in Crimson. Floating-point values from V. are IEEE-754 single-precision and require no byte swap beyond the natural big-endian/little-endian translation handled by Crimson.

Step 7: Verification Procedure

1. Compile check: Build the APT program with the TEST UNIT enabled. The compiler should report zero errors and zero warnings about read-only addresses.
2. Download: Transfer the program to the TI555-1106 and place the CPU in Run.
3. Online monitor: Open the APT online status screen. Watch X1. From the AB simulator or DA30D, write 1 to V100. Confirm that X1 transitions to 1 within one scan.
4. Analog verification: Write a floating value of 123.45 to V.50. Confirm that WX10 shows the expected raw integer equivalent after the scaling pass-through.
5. Round-trip test: Toggle a discrete input via the simulator and verify that the TI555 logic drives the expected Y output, which the DA30D echoes back to the AB PLC. A full round-trip in under two scans confirms the architecture is intact.
6. Stop condition: Place the CPU in Stop. The X/Y and WX/WY memory should hold their last values — this is a useful diagnostic to confirm the I/O scanner is not active.
7. Forced value check: From APT online, force X1 = 1 and WX10 = 12345, then cycle power. If the values reappear on the next cold start, both simulation memory and the address trick are confirmed persistent.

Acceptance checklist

Troubleshooting Matrix

Limits and Field-Proven Caveats

• No hot-swap: The TI555 base does not support live I/O removal in the way that a modern S7-1500 with PROFINET does. Plan downtime and LOTO for module removal.
• Per-slot applicability: The technique only works for slots whose input card has been removed. If slot 4 holds a populated input card, X/WX writes to that slot will be overwritten every scan.
• Compiler does not track physical reality: APT's syntax check assumes I/O exists. It is the engineer's responsibility — not the compiler's — to verify which slots are physically populated before relying on a write-through Y trick.
• Floating-point alignment: Each V. address consumes 32 bits and must be aligned to an even 16-bit boundary in the underlying V space. Crimson mapping must respect this or float values arrive scrambled.
• Surviving power cycles: If the TI555 battery is healthy, V/V. memory and the X/Y/WX/WY image are retained across power cycles. Simulation values written from the DA30D reappear on the next cold start — usually desirable but worth documenting.
• Firmware version sensitivity: The exact ranges of V/V. memory depend on the TI555-1106 firmware revision. Newer firmware exposes larger V memory areas. Verify the actual range in APT's Memory Map dialog before commissioning.
• Production logic must stay read-only on X: Do not have any production UNITs that write to X or WX via the address trick while a real input card is also installed in the corresponding slot — this creates a bus-content race that produces nondeterministic behavior.
• DA30D scan time vs TI555 scan time: DA30D poll periods are typically in the 100–500 ms range, while the TI555 program scan is typically 10–50 ms. Brief glitches in X between simulator updates are expected and are not a fault of the technique.
• Crimson project version control: Always archive the Crimson project file alongside the APT project. The two are inseparable at commissioning — either both are restored or neither will function correctly.

Before/After Comparison

Power-On State Behavior

The following sequence describes what happens during a TI555 cold start with the simulation configuration in place and a healthy battery.

Edge Cases and Special Conditions

Frequently Asked Questions