Accumulating timer memory overlap: why TA1 stops your timer

Why does an accumulating timer stop a standard timer?

A TMRA or TMRAF accumulating timer stores its preset and its accumulated value as double words, two 16-bit registers each, so an accumulating timer at T0 keeps its total in TA0 and TA1, and TA1 is also the register where standard timer T1 keeps its current value.

A standard timer needs one register. Its value climbs from zero to the preset, the done bit fires, and the sequence moves on. With an accumulating timer running at the number below, TA1 holds the top half of that total, and every comparison your ladder makes on TA1 now reads the top of the accumulator. The changeover logic waits for the register to sit at its preset; the top half of a growing total matches it at the wrong moments or never, so the sequence stalls with the start relay on. The accumulating timer can be perfectly healthy. The fault is allocation: two instructions own one register.

Which symptoms point to a timer overlap instead of a bad preset?

The pattern is a timer that used to finish and now never does, with its current value on the display changing while nothing in the sequence logic should be changing it, and a preset that reads exactly the value you programmed.

Work down the list:

• TA1 flips between 0 and 1 while the start relay is on. The register has a second writer. What you are watching is the high word of a neighboring double-word accumulator.
• The done bit never fires even though the preset reads correctly. The current-value register is kept updated by another instruction, so the comparison never finds the preset sitting in it.
• The sequence ran for days or weeks and broke with no program change. An accumulating total grew past 9,999, the largest number four BCD digits hold, and its fifth digit entered the shared register for the first time.
• The fault began right after a timer was added or retyped. The new double-word instruction took the register pair that included your timer's current value.
• The preset on screen differs from the approved delay. Stop at that bullet. That is a changed preset, not an overlap: restore the approved value, run one controlled sequence, and go on only if the sequence still stalls.

What do I check before I change any logic?

Read the preset first: open the timer instruction for the sequence timer, read its preset against the approved delay, and treat a matching preset as a sign the fault is allocation, because no preset edit brings a sequence back when a second instruction owns the value register.

If the preset differs from the approved value, restore it and test once; a changed preset explains a changed transition time. If the preset matches, leave the instruction alone and go to the cross-reference. Repeated preset edits in that state only stack a second fault on the first.

How much memory does an accumulating timer use?

A TMRA or TMRAF instruction uses twice the storage of a standard timer: one 16-bit register for a standard timer's current value against two registers, 32 bits, for an accumulating timer's current value, and the same doubling applies to the preset when the preset lives in a V register.

Each 16-bit register carries the value as four BCD digits, so one register spans 0 to 9,999 and the double word carries the digits beyond that in its second register. The doubling touches three places at once:

The third row is the planning consequence: an accumulating timer at T0 takes the numbering space of T0 and T1, so the next number you can safely assign starts at T2. The same width mismatch bites comparisons anywhere else in the project; fixing a PLC hour compare that reads a single word instead of a double is the same lesson with a run-hour total.

Example: what happens when the accumulator passes 10,000?

At a total of 10,000 the accumulated value needs a fifth BCD digit, four digits being the most one 16-bit register holds, so the fifth digit lands in the high register TA1 and reads there as 1 while your sequence timer's value should be counting toward its preset.

Scenario: a cooling changeover with a maintenance total in the same program.

• T0 is a TMRA accumulating the seconds the lead unit runs, preset 20,000 s as a service reminder. 20,000 s ÷ 3,600 s per hour = 5.6 h of run time.
• T1 is a standard timer, the changeover delay, preset 5 on its own time base, giving the stagger between the two commands.
• T2 is another standard timer elsewhere in the sequence, so the changeover cannot move there.

While the total stays at 9,999 or below, TA0 holds at most 9999 and TA1 holds 0. T1's value register reads 0 while the sequence is idle, which looks exactly right, and the fault sits fully present and invisible.

One second later the total is 10,000: one lot of 10,000 plus nothing, so the low register holds 0000 and the high register holds 1. TA0 = 0000, TA1 = 1, and that 1 is now also T1's current value. The comparison waiting for TA1 to reach 5 never sees a changeover count at all; it sees the top of T0's total. The done bit never fires, the start relay stays on, the second unit never gets its delayed command, and TA1 on the display flips from 0 to 1 every time the total resets and climbs back.

The collision can also fire early. A total of 50,000 puts 5 in the high register, because 50,000 = 5 × 10,000 + 0, and a 5 matches T1's preset of 5, triggering the done bit at a moment the sequence never intended. Moving the changeover timer and every reference to T3 and TA3, the next number with a free register pair, puts the sequence back to work.

How do I find every instruction that writes TA1?

Run the cross-reference on TA1 and on T1 before you change anything: the listing should show every contact, comparison and mapping that reads or writes the register, and you are looking for a second writer, the accumulating timer instruction at the number below.

1. Search the project for TA1 and for T1. The hits should cover timer instructions, compare contacts, moves, reset logic and the two sequence commands to the units.
2. Mark each hit as a reader or a writer. A display mapping that only reads the register can stay; a mapping that writes it is a second owner.
3. Open the instruction at the number below, T0, and confirm its type. TMRA or TMRAF there claims TA0 and TA1 as one double word, and the case is closed.
4. If the project keeps presets in V registers, check the preset registers too: the accumulating timer's preset occupies two adjacent registers, and the neighbor of its preset belongs to T1.
5. Check startup transfers between the display and the PLC. A panel writing retained values at startup is one more writer of the same register; why an HMI overwrites PLC retained variables at startup walks through that case.
6. When you map the total onto a board or panel later, read both registers and reassemble the number before showing it; that is the same two-register problem as displaying a PLC float stored in two word registers on an HMI.

Ladder packages that check operand widths catch some of these collisions when the project compiles. For a package without that check, the walkthrough of detecting register overlap in double-word instructions in GX Works2 shows what a software check of a double word's neighbor looks like.

Which timer number is safe for the sequence timer?

Any number whose whole block is free: with an accumulating timer at T0 that is T2 or higher, because T0's double word claims TA0 and TA1, and the habit that prevents the next collision is numbering timers in steps of 2 so every accumulating timer has an empty neighbor.

Two standard timers can sit next to each other, T2 and T3, because each uses a single register. The gap matters only next to a double-word instruction. Numbering every timer in steps of 2 (T0, T2, T4) costs nothing and means any timer can be retyped as an accumulating timer later without taking a neighbor's register. Before you rely on a moved number, the cross-reference must show its value register and its preset register free; the spacing habit plans the layout, and the audit clears the specific project.

Recommendation: Number timers in steps of 2 from the start of a project, T0, T2, T4, and put any TMRA or TMRAF on one of those numbers; after any change to a timer's type, rerun the cross-reference on the value register and the preset register before you download to the PLC.

How do I prove the changeover works after the move?

Watch one controlled sequence online: the start relay still starts the timer, the current value counts up to the preset and stops, the done bit fires at the set delay, and the off command to the first unit precedes the on command to the second by that delay.

One safety note: the done bit commands real equipment, so make the first controlled test with the units in a state where a wrong command damages nothing.

1. Save the project and record the original assignments, T1 and TA1 with the preset, before editing anything.
2. Confirm in the cross-reference that the target number's value register and preset register are unused.
3. Move the instruction and every reference as one set: the timer instruction, the comparisons, the reset logic and any display mapping. A partial move leaves the comparisons reading the old register.
4. Download and run one full changeover: start it from the display toggle, watch the value climb to the preset unaided, watch the done bit reset the start relay, and confirm the off command lands before the on command with the programmed delay between them.
5. Run the sequence a second time to confirm the timer starts clean, and watch TA1 during the run: with the collision gone, the register holds only your timer's count.
6. If the value still moves when no sequence logic should be moving it, a writer remains on the list; go back to the cross-reference hits and clear the next one.

If the run total should also be visible on a board away from the machine, displaying a PLC counter value where operators can see it covers what a separate notice screen can take from the PLC and where that board belongs on the wall.

Questions