Configuring DL205 Timer Presets from an EZText Panel Value

A DL205 (240 CPU) timer that must run one of three presets, selected by a 1-3 menu value the EZText 220P writes into V4020, does not work when each choice gets its own TMR T1 rung. The fix is one TMR T1 instruction whose preset comes from a single V-memory register, plus logic that copies the chosen preset into that register.

Skip the duplicate TMR T1 rungs

The obvious attempt is one rung per menu value, each ending in the same timer:

V4020 = K1 ----- TMR T1  V4001
V4020 = K2 ----- TMR T1  V4002

It fails for a scan-order reason. A TMR instruction accumulates only while its own rung is true, and it resets the timer when its rung is false. With two TMR T1 instructions, the rung whose condition is false executes every scan and clears the accumulated value that the true rung just built. One timer number must appear in exactly one TMR instruction.

Two other quick fixes also fail:

• Adding T2 and T3 so each menu value has its own timer. This runs, but it triples the timer count, and downstream logic then has to pick among three done bits.
• Moving the compare contacts in front of the timer enable. The enable is then true only for the matching value, so the timer resets whenever the menu value changes, and the duplicate-instruction problem remains.

Check before moving on: search the program for T1 in DirectSOFT (cross-reference). It must appear in one TMR instruction only. Remove the extra ones now.

Reserve one selected-preset register

Pick an unused V-memory word to hold the preset the timer actually uses. The examples here use V2000 as a placeholder; take the real address from your own memory map and confirm nothing else writes to it.

If you have not yet assigned a third preset word, allocate it next to V4001/V4002 so the panel screen maps cleanly.

Check: monitor V4020, V4001, V4002 and your chosen selected-preset word in a data view. Change the menu on the panel and confirm V4020 follows it before you write any logic.

Load the selected preset with compare contacts, LD and OUT

Use one rung per menu value. Each rung has an equality compare on V4020 and a LD/OUT pair that copies the matching preset into the selected-preset register:

V4020 = K1 ----- LD V4001 --- OUT V2000
V4020 = K2 ----- LD V4002 --- OUT V2000
V4020 = K3 ----- LD (third preset word) --- OUT V2000

Only one compare is true at a time, so only one copy executes per scan. This is the same pattern that worked in the field: the copies are plain LD/OUT pairs, and the timer sees a single stable register.

An equivalent layout puts the three copy rungs in a dedicated stage (RLL^PLUS) that stays active and only watches the panel's V-memory, dumping the values into the preset registers. Use whichever fits your program structure; the logic is identical.

Two details decide whether the copy behaves:

• Data format. The K constants in the compares are BCD in the DL205. Confirm the panel field for V4020 is set to a format the PLC reads as BCD, or the compare against K1-K3 can still match while larger preset values are misread.
• Out-of-range value. If V4020 is 0 or above 3, no rung fires and the selected-preset register keeps its last value. Add a default rung (or limit the panel field to 1-3) so a bad entry cannot leave a stale preset.

Check: step V4020 through 1, 2 and 3 from the panel. The selected-preset word must show the matching preset value each time, within one scan.

Point the single TMR at the selected preset

Replace all timer rungs with one:

Use your real timer-start contact for . Do not use SP1. SP1 is the always-on special relay; a timer enabled by it runs once after power-up or RUN transition and never resets, so it never times again. Use SP1 only as a stand-in while testing, or where a subroutine is entered and left so the rung goes false between calls.

A V-memory preset on a DL205 TMR is read as BCD. Timer resolution on TMR

Check: with the run condition true, watch T1 in status view. It must accumulate continuously and set at the preset for the selected menu value, not just at V4001.

Decide what happens when the operator changes the menu mid-run

A preset change while T1 is timing does not act on the fly. The new value lands in the selected-preset register immediately, but the running timer completes its cycle with the preset it started under, and the new value takes effect after the timer is reset by its run condition going false. In practice: the operator sees the panel accept the change, and the process does not change until the next cycle.

Two choices:

1. Accept it. Fine when a late preset change is harmless. This is the case in the installation this article covers, where a delayed update does no damage.
2. Interlock the copy. Add a normally-closed contact for the timer's run condition (or for the timer running) in series with the three copy rungs. The selected preset then updates only while the timer is idle, and the value the operator sees on the panel matches the value in use whenever a cycle starts.

Choose the interlock when a mid-cycle change could give a wrong process time, since a timer that finishes at the old preset while the panel shows the new one misleads the operator.

Check: start the timer, change V4020 from the panel, and note the selected-preset word changes (no interlock) or holds (interlock). Let the cycle end, restart, and confirm the new preset is used.

Run the end-to-end check before releasing the machine

1. Cross-reference T1: exactly one TMR T1 instruction.
2. Set the panel to 1, start the timer, and measure the elapsed time against the value in V4001.
3. Repeat for 2 and 3 against their preset words.
4. Edit a preset word from the panel and confirm the selected-preset register reflects it on the next idle copy.
5. Enter an out-of-range menu value (0 or 4). The selected preset must hold a defined, safe value.
6. Change the menu mid-run and confirm the behavior matches the option you chose above.
7. Cycle the PLC from RUN to STOP to RUN and confirm the selected preset repopulates from V4020 before the first timed cycle.

Separate the temporary restore from the permanent repair: to get production running quickly, hard-code a single TMR T1 K value for the one setting in use; then apply the shared-register logic above and remove the constant.

Common failure symptoms and causes

FAQ