The symptom: a Productivity2000 TMR with the reset when timer reaches preset value option enabled never shows =Preset (.Equal) going high. The reported setup was Productivity Suite 3.1.0 (11) on a P2-550 CPU with firmware 1.2.2.75. Two things can produce this, and they need different fixes. The bit may be a one-scan pulse that your monitor never catches. Or the instruction may reset the accumulator before it evaluates the condition flags, so the bit is never set at all. Work through the checks below in order. Get it running, then fix it properly.
Skip the Quick Fixes That Don't Work
These get tried first on night shift. None of them tells you which of the two causes you have.
- Watching the bit in Data View. A one-scan bit is true for a few milliseconds at most. The monitor refresh is far slower than the CPU scan, so a working one-scan bit and a dead bit look identical on screen.
- Lengthening the preset. A longer preset only changes how often the pulse happens. The pulse stays one scan wide, and the monitor still misses it.
- Waiting on a firmware update. If the instruction resets before it sets its flags, the behavior can be read as intended, and the option works as written. Plan your logic around current behavior.
- Moving the rung around. Rung order changes which rungs see a one-scan bit. It does not make a bit appear that the instruction never writes.
Check 1: Confirm What the Timer Is Configured to Do
Open the TMR instruction dialog and record three things before testing:
- Is the reset when timer reaches preset value option checked?
- Which tags are assigned to
=Presetand>Preset? Are they separate tags or the same tag? - What data type is the current value tag?
Outcome: If the reset option is off and .Equal still never appears in logic, skip to Check 4. If the option is on, go to Check 2. Also note your Productivity Suite and CPU firmware versions from the project and CPU status screen; you will need them if this goes to support.
Check 2: Trap the .Equal Bit With a Counter
Stop trying to see the bit. Make the logic record it. Feed .Equal into a counter, or latch a spare bit with it, in a rung placed below the timer. Use a short preset so you get many cycles in a minute.
(Tag names are examples; use your own.) Run it for a known time and compare Test_Ctr to the expected number of cycles.
| Counter result | Meaning | Next step |
|---|---|---|
| Counts roughly one per cycle | The bit works. It is one scan wide and the monitor missed it. | Use the bit in logic below the timer, or trap it. Done. |
| Stays at zero, latch never sets | The instruction resets the accumulator before evaluating the flags. = and > are never set. |
Go to Check 3 to confirm, then apply the self-reset fix. |
| Counts some cycles, misses others | Equality is being hit sometimes and skipped sometimes. | Go to Check 4. |
Why the zero-count case happens: When the instruction executes and finds the accumulator at or past preset, the reset option zeroes it inside that same execution. By the time the instruction reaches the point where it writes the condition flags, the accumulator is back below preset, so neither flag qualifies. The option is aimed at applications that only compare the current value externally, for example several events staged at different times during a single cycle, where the preset flags are never needed.
Check 3: Repeat the Test With the Reset Option Off
Uncheck the reset option. Drive the timer's Reset input from a manual bit instead. Let the timer run past preset once and check the trap from Check 2.
-
Counter increments once and
>Presetgoes high and stays high: The flags work. The reset option is what suppresses them. Go to the fix section. - Counter still stays at zero: The problem is not the option. Go to Check 4.
Stop here if you have limited downtime: the confirmed branch is "option suppresses flags," and the fix below restores production without further testing.
Check 4: Read the Current-Value Data Type and Step Size
A timer accumulator advances by the elapsed time since its last execution, which is roughly one scan. It moves in steps, not continuously. Whether =Preset is set on the scan the value crosses preset or only when the value lands exactly on it decides whether this bit is reliable in your program.
- Confirm the data type of the current value tag in the instruction dialog. Watch the value in Data View near the preset and note the step size between readings.
- With the reset option off, log the current value on the scan the trap fires (copy it to a spare tag in the rung that sets the latch).
- If the captured value sits exactly at preset every time, equality is effectively a crossing detector and you can rely on it. If the counter misses cycles, do not use
.Equalalone for anything that must fire every cycle. Use the combined>=flag described below.
Symptoms vs. Causes
| Symptom | Likely cause | Resolving action |
|---|---|---|
.Equal never visible in Data View, trap counter counts |
One-scan bit, monitor too slow | Trap or use the bit directly in logic below the timer |
| Trap counter stays at zero with reset option on, counts with option off | Instruction resets before writing condition flags | Turn option off; self-reset from .Equal on the Reset input |
| Trap counter misses some cycles | Accumulator steps past preset without an exact-equal scan | Share one tag for =Preset and >Preset to get >=
|
Rungs above the timer never react to .Equal
|
Bit set and cleared within the rungs below in one scan pass | Move dependent logic below the timer, or latch the bit |
Fix: Self-Reset From .Equal Instead of the Built-In Option
If you need the preset flag, do not use the reset option. Reset the timer with its own output.
- Uncheck reset when timer reaches preset value.
- Put a normally open contact of the timer's
.Equaltag (or the shared>=tag from the next section) on the timer's Reset input. - Place every rung that consumes the pulse below the timer rung, or make sure the consumer logic tolerates seeing the bit on the next scan.
- Download and run the Check 2 trap again. The counter should now track the expected cycle count.
Rung 1: TMR Enable: Cycle_Run
Reset: --[ NO Cycle_Tmr.Equal ]--
=Preset -> Cycle_Tmr.Equal
Rung 2: Cycle_Tmr.Equal ----[ do the once-per-cycle action ]How it sequences: On the scan the timer reaches preset, the instruction sets .Equal and every rung below sees it. On the next scan the Reset input reads the bit as true and clears the timer, which clears the flag. The pulse is one full scan cycle wide, so every rung in the program gets exactly one look at it.
Pitfall: each cycle is the preset plus about one scan, plus any amount the accumulator overshot preset before the reset. That error accumulates. If a repeating timer must hold long-term cadence, compare the total against a real-time clock over a long run, or subtract the overshoot instead of zeroing.
Build a >= Preset Flag From One Tag
A common approach: assign the same tag to both =Preset and >Preset. The equal flag is true for the one scan the value reaches preset, and the greater-than flag takes over from the next scan on. The tag behaves as a >= flag and does not depend on catching an exact-equal scan.
This depends on how the instruction writes its flags. If it clears all condition tags and then sets the relevant ones, a shared tag works. If it writes each flag in turn, the last write wins, and a false = written after a true > would clear the shared tag. It has been used without that failure, but the internal write order is not documented behavior, so prove it on your firmware:
- Run the timer with the reset option off and no reset, past preset, for well over the preset time.
- Count falling edges of the shared tag with a one-shot into a counter.
- Pass: the tag goes high once at preset and stays high; falling-edge count is zero until you reset the timer.
- Fail: any falling edges while the timer is past preset. Use separate tags and OR them in logic instead.
Re-run this test after any CPU firmware or Productivity Suite update. Instruction internals can change between releases.
Verify Before Handing Back
- Trap counter matches expected cycles over at least a few minutes of running.
- Shared-tag falling-edge counter reads zero while the timer runs past preset (if you used the
>=method). - Every consumer of the pulse is below the timer rung or handles a one-scan delay.
- Remove or disable the test counters and latches, or leave them documented as diagnostics.
- Record the firmware and software versions tested in the project notes.
FAQ
How do I see a one-scan timer bit in Productivity Suite?
You won't see it reliably in Data View because the refresh is slower than the scan. Feed the bit into a counter or a Set instruction in a rung below the timer and watch that instead.
How do I get a repeating timer with a preset pulse on a P2000?
Uncheck the reset-at-preset option and put a normally open contact of the timer's .Equal tag on its Reset input. The bit stays true for one full scan cycle, then the timer resets on the next scan.
How do I make a greater-than-or-equal preset bit on a Productivity TMR?
Assign the same tag to =Preset and >Preset, then confirm with a falling-edge counter that the tag never drops while the timer runs past preset. If it drops, use separate tags and OR them in a rung.
When should I call AutomationDirect support about the TMR reset option?
Stop and escalate if the .Equal trap counter stays at zero even with the reset option off, or if the shared-tag test shows falling edges on your firmware. Send AutomationDirect technical support the Productivity Suite version, CPU model and firmware, the timer rung, and your trap counter results.