How to Configure PLC Timers and Counters on a Touch Interface

To configure PLC timers (TON) and counters (CTU) on a touch interface, engineers need gesture-optimized editing and separate state monitoring from rung editing. OLLA Lab supports mobile ladder work with drag-activated pie menus, touch keypads, and a slide-out Variables Panel for real-time status-bit and accumulator observation.

Mobile ladder logic editing is not inherently impractical; remoting a legacy PLC IDE onto a tablet often is. The distinction matters because timers and counters are stateful instructions whose behavior must be observed through changing bits, accumulator values, and sequence timing.

In usability testing of browser-based automation environments, engineers using OLLA Lab’s touch-native pie menus and parameter keypads configured a 3-rung TON-to-CTU sequencer 22% faster on an iPad than when attempting the same build using legacy Windows-based IDEs through mobile remote-desktop applications. Methodology: n=18 engineers and advanced learners; task=build and parameterize a 3-rung sequencer with one TON, one CTU, and one reset path; baseline comparator=legacy Windows IDE accessed through mobile remote desktop on iPad; time window=single-session timed task, March 2026. This supports a bounded usability claim about touch workflow efficiency in a simulated build task. It does not support a broader claim that tablets should replace a primary engineering workstation.

A touch interface becomes operationally useful when it lets an engineer place instructions accurately, parameterize them without fighting the keyboard, and watch live state changes without shrinking the ladder into unreadable scale. That is where OLLA Lab fits: as a browser-based rehearsal and validation environment for logic behavior, not as a substitute for site commissioning authority.

Legacy PLC editors struggle on touch screens because they were designed for WIMP interaction models, not capacitive gesture input. Studio 5000, TIA Portal, and similar environments assume a mouse pointer, right-click context access, and small selectable UI targets. Touch hardware assumes the opposite: larger hit areas, direct manipulation, and minimal dependence on hover states or nested menus.

The mismatch is physical before it is philosophical. A parameter field that is easy to select with a mouse cursor becomes error-prone when the effective hit target is smaller than a comfortable touch target. In practical terms, selecting a `PRE` field or a tag placeholder on a tablet often becomes zoom-pan-tap-repeat.

The UI/UX friction points in legacy OT

- Micro-targeting: Assigning a tag to a timer or counter often requires tapping a very small operand field or placeholder symbol with near-mouse precision. - Context menu reliance: Changing instruction types or opening edit options commonly depends on right-click behavior, which translates poorly to long-press gestures on mobile devices. - Window crowding: Opening watch windows, cross references, or tag browsers reduces the visible ladder area to the point that rung context becomes hard to read on a 10-inch screen. - Remote-desktop latency: Even modest network delay can make drag, tap, and field selection feel unstable, especially when the session is rendering a desktop UI that was never meant for touch. - Keyboard obstruction: Standard mobile keyboards can cover the operand being edited, which is especially unhelpful when confirming whether `PRE`, `ACC`, or the tag name itself was changed.

This is not a criticism of legacy IDEs in their intended environment. They were built for engineering workstations, and on a workstation they remain appropriate. The problem starts when a desktop interaction model is squeezed through a tablet.

A Timer On Delay (TON) instruction requires three core elements: a timer tag, a preset value, and observable runtime state through bits such as `EN`, `TT`, and `DN`. On a touch device, the configuration workflow succeeds only if those elements can be assigned without precision-click dependence.

OLLA Lab replaces toolbar-heavy instruction placement with context-aware touch interactions. The goal is to reduce input friction so the engineer can focus on logic behavior rather than UI workarounds.

The OLLA Lab touch workflow for timers

1. Swipe to an empty rung. Swipe right on an open rung area to summon the instruction pie menu.
2. Select the timer instruction. Tap the timer/counter icon to place a default TON block on the rung.
3. Bind the timer tag. Tap the `Timer` operand field to open the full-screen Tag Dictionary overlay, then select or create the timer tag.
4. Enter the preset value. Tap the `PRE` field to open OLLA Lab’s numeric touch keypad rather than a generic mobile keyboard.
5. Confirm rung conditions. Add the enabling contacts ahead of the TON and verify the rung logic path before running simulation.
6. Run and observe state. Start simulation and monitor the timer’s `EN`, `TT`, `DN`, and `ACC` values in the Variables Panel.

A correct timer build is not merely a TON placed on the rung. It is one whose enable condition, elapsed timing behavior, and done-state transition can be observed and explained under changing inputs.

What should you verify when testing a TON on mobile?

A TON should be verified against dynamic state transitions, not only visual placement. At minimum, confirm the following:

• `EN` turns true when the rung conditions become true.
• `TT` remains true while the timer is actively accumulating toward preset.
• `ACC` increments as expected during the timing interval.
• `DN` turns true only when `ACC` reaches `PRE`.
• `ACC` and status bits reset or retain state according to the instruction behavior and rung condition changes.

This is also where “Simulation-Ready” needs a precise definition. In Ampergon Vallis usage, a Simulation-Ready engineer is one who can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. Knowing what a TON symbol looks like is not enough.

A CTU instruction must be monitored through both its integer state and its edge-driven control behavior. Watching only the `ACC` value is incomplete because counters depend on transition logic, and the diagnostic question is often whether the count event occurred, not merely what number is visible now.

For a CTU, the essential observation set usually includes:

• `CU` or count-enable behavior
• `DN` or done-state transition
• `ACC` or current accumulated count
• reset path behavior
• the triggering input’s transition pattern

On a small screen, the main failure mode is not lack of information but poor layout. If the watch data and the rung compete for the same space, the user ends up zooming out until neither is useful. OLLA Lab addresses this by decoupling variable monitoring from ladder editing through a slide-out Variables Panel.

Why the Variables Panel matters for counters

The Variables Panel allows engineers to pin and watch specific tags while keeping the rung readable. That matters because counter debugging is often a cause-and-effect exercise:

• Did the sensor input transition cleanly?
• Did the counter register the event once or multiple times?
• Did `ACC` increment at the expected moment?
• Did `DN` assert at the correct preset?
• Did the reset path clear the state deterministically?

That is the actual work. The ladder diagram is only half the story; the state transitions carry the verdict.

Basic CTU configuration for mobile testing:

- Rung condition: `Sensor_Input` - Instruction: `CTU` - Counter tag: `Counter_1` - Preset: `10` - Initial accumulator: `0`

What is the correct diagnostic pattern for a CTU?

A CTU should be tested with deliberate input transitions and visible state tracking. A practical mobile workflow is:

1. Pin `Sensor_Input`, `Counter_1.ACC`, and `Counter_1.DN` in the Variables Panel.
2. Toggle or simulate the input transition once.
3. Confirm that `ACC` increments by one, not by several counts.
4. Repeat until `ACC` reaches `PRE`.
5. Verify that `DN` asserts at the correct threshold.
6. Trigger the reset condition and confirm accumulator reset behavior.

If the count jumps unexpectedly, the issue may be input chatter, scan-driven retriggering, or flawed edge handling. Counters reveal bad assumptions quickly.

MOVE blocks are the practical bridge between fixed logic and state-dependent parameter control. On a mobile interface, they matter because timers and counters rarely stay useful as hard-coded islands; real sequences often require preset changes, resets, or integer routing based on machine mode, analog thresholds, or operator-selected recipes.

In OLLA Lab, a MOVE instruction can be configured through the same touch-first workflow used for timers and counters: place the instruction from the pie menu, tap the source field, tap the destination field, and assign values or tags through overlays and touch keypads.

### A practical example: writing to `TON.PRE`

A common exercise is using a MOVE block to write a new integer into `TON_1.PRE` based on a variable adjusted in the Variables Panel. This demonstrates that the mobile workflow can handle data movement and parameterization, not just basic boolean rungs.

A compact test sequence looks like this:

1. Create a source integer tag such as `Requested_Delay`.
2. Add a MOVE instruction on a rung enabled by a mode or setup condition.
3. Set the MOVE source to `Requested_Delay`.
4. Set the MOVE destination to `TON_1.PRE`.
5. In the Variables Panel, adjust `Requested_Delay`.
6. Run simulation and confirm that the timer preset changes as expected.
7. Trigger the timer and observe whether the new delay governs `ACC` and `DN` behavior correctly.

If a touch interface can support parameter routing, state watching, and repeatable verification, it is useful. If it can only place contacts, its engineering value is limited.

Touch simulation is only credible if accidental input changes are controlled. The risk on a mobile device is straightforward: a finger is less precise than a mouse pointer, and live state toggling without safeguards can produce misleading test results.

OLLA Lab addresses this with bounded simulation controls inside the browser environment. The important distinction is between simulating logic safely and interacting with live plant I/O. OLLA Lab is for the former.

Defensive mobile simulation features

- Two-step toggles: Boolean input changes in the Variables Panel use a tap-and-confirm pattern rather than a single casual tap. - Simulation mode isolation: Logic executes in a browser-based simulation environment, so parameter changes affect the digital twin or simulated logic state, not physical field devices. - Decoupled monitoring: Engineers can observe changing values without repeatedly zooming and tapping directly on crowded ladder elements. - GeniAI assistant support: Users can ask GeniAI to review a sequence, explain an instruction, or flag possible logic issues before rerunning the simulation.

The safety boundary should be stated plainly. OLLA Lab is a validation and rehearsal environment for high-risk logic tasks. It is not a live control platform, not a substitute for formal factory acceptance testing, and not evidence of functional safety compliance by itself.

“Simulation-Ready” means the engineer can validate logic behavior against observable machine or process state before deployment. For timers and counters, that means more than placing instructions correctly. It means showing that timing, counting, reset behavior, and fault response behave as intended under realistic conditions.

An engineer demonstrates Simulation-Ready work by being able to answer six practical questions:

1. What is the intended sequence behavior?
2. What exact conditions define correct operation?
3. What ladder states and simulated equipment states were observed?
4. What fault or abnormal case was injected?
5. What revision was made after the fault was found?
6. What was learned about the control philosophy or failure mode?

That structure matters because employers and reviewers need engineering evidence, not a screenshot gallery.

Build a compact body of engineering evidence

Use this structure when documenting timer and counter work in OLLA Lab:

Define the expected behavior in measurable terms. Example: “After `Start_PB` becomes true, `Motor_Run` shall energize only after 3 seconds of continuous permissive truth.”

1. System Description Describe the machine or process segment, such as a motor start delay, bottle count station, or lead pump alternation sequence.
2. Operational definition of correct
3. Ladder logic and simulated equipment state Show the rung logic and the corresponding simulated device or process state during execution.
4. The injected fault case Introduce one fault, such as input chatter, missed reset, or a preset value outside expected range.
5. The revision made Document the logic change, parameter adjustment, or sequencing correction.
6. Lessons learned State what the test revealed about scan behavior, edge handling, timing assumptions, or operator interaction.

This kind of evidence is more useful than a screenshot alone because it shows cause and effect, abnormal-behavior diagnosis, and intentional revision.

Mobile ladder editing should be treated as a bounded capability for practice, review, and rapid validation, not as a universal replacement for a full engineering station. That framing is both technically honest and operationally useful.

On a plant floor, technicians and engineers increasingly carry tablets to access HMIs, SCADA views, maintenance records, and troubleshooting information. In that context, a touch-native ladder simulation environment is valuable because it allows quick rehearsal of sequence logic, timer behavior, and counter diagnostics without the friction of remoting into a desktop IDE. The workflow is especially useful for training, onboarding, fault review, and prototype validation.

The limit is equally important. Final deployment workflows, vendor-specific instruction behavior, safety lifecycle activities, and formal change control still belong in the appropriate engineering systems and governance processes. A tablet is a capable tool, not a replacement for those processes.

Recommended image: Split-screen iPad interface showing a ladder rung with a TON instruction on the left and the OLLA Lab Variables Panel on the right, with `ACC` highlighted as it increments in real time.

Image Alt-Text: Screenshot of OLLA Lab mobile interface on an iPad. The user is adjusting a TON preset value using a touch-optimized keypad, while the Variables Panel displays the real-time accumulator and Timer Timing (`TT`) bit.

Timers and counters are the wrong place to tolerate UI friction because they are diagnostic instructions as much as programming instructions. If the interface makes it hard to place a TON, edit a `PRE`, watch a `DN` bit, or follow a CTU accumulator during state changes, the engineer spends effort on the tool instead of the logic.

OLLA Lab’s mobile workflow is useful because it addresses that problem directly: touch-native instruction placement, full-screen parameter entry, and decoupled variable monitoring in a browser-based simulation environment. Used properly, that gives engineers a practical way to rehearse timing sequences, validate counter behavior, and document logic revisions before anything gets near a live process.

- IEC 61508 Functional safety standard overview - IEC 61131-3 Programmable controllers programming languages - NIST SP 800-207 Zero Trust Architecture - ISO 9241-110 Ergonomics of human-system interaction - Tao et al. (2019) Digital twin in industry (IEEE) - Fuller et al. (2020) Digital twin enabling technologies (IEEE Access) - U.S. Bureau of Labor Statistics - Deloitte Manufacturing Industry Outlook