PLC Two Hand Control Program: Timing and Release Tests

This PLC two hand control program is a disconnected two-input timing exercise. It accepts a virtual request only after both inputs have been observed released, checks the interval between their activation observations, and requires another complete release before a new attempt after either input drops.

The output is named AcceptedRequest. It is not a press valve, a motor command or a validated safety output. The example supplies no button installation, actuator circuit, stopping-distance assessment or physical press-control design. A Boolean becoming false cannot prove that a press opens or that motion stops.

For South African PLC learners, the lesson develops three distinct ideas: both inputs being true now, their activation timing, and the release history needed for another attempt. Passing one of those tests does not automatically establish the other two.

Keep the timing exercise distinct from a safety function

Two-hand operation of machinery involves more than an ordinary AND expression and a timer. This page studies a small event model with two supplied Boolean inputs. It does not establish an ISO classification, a performance level, a safety integrity level or compliance of any installation.

For comparison, Rockwell Automation’s Two Hand Run Station documentation describes a specific instruction for listed controllers. It processes four button-contact inputs, includes fault and cycle-related indications, and lists availability in ladder diagram rather than structured text or function block.

Those documented features are not implemented by the two-input model below. Its pseudocode should not be substituted for that instruction or represented as an equivalent safety function. When reading a manufacturer’s example, retain the context of its controller, instruction and documented application conditions.

The purpose here is to predict and test software observations. No physical spacing between controls is prescribed, and no generic timer value is claimed to validate a machine’s response. Keep any real machinery assessment outside the conclusions supported by this exercise.

Define the input meanings and strict timing boundary

LeftInput and RightInput are true while the respective virtual input is requested. Permission is a supplied Boolean that permits the lesson’s acceptance logic to operate. Permission false clears any active request and requires a new observed release after it returns.

Use nondecreasing whole-number timestamps in milliseconds. The illustrative acceptance window is strictly less than 500 ms from the first observed single input to the observation of both inputs true. An elapsed value of 499 ms can be accepted; 500 ms or more is rejected.

That strict boundary is a deliberately stated learning rule. It is not a claim about the exact boundary semantics of every manufacturer’s two-hand instruction or a quotation from a safety standard. If another implementation uses an inclusive boundary, its expected tests must reflect that difference.

If both inputs first become true in the same evaluation after Ready, the model accepts that observation as simultaneous for its purposes. It cannot recover the true interval between physical events that occurred between samples. “Observed together” and “physically simultaneous” are different claims.

The ladder logic basics guide can help with the Boolean conditions. The scan-cycle explanation is useful for understanding what an evaluation observes and what remains outside that observation.

Use states that preserve the first-input history

Use NeedsRelease, Ready, WaitingLeft, WaitingRight, Active and Rejected. WaitingLeft means LeftInput was observed first and remains required while waiting for RightInput. WaitingRight is the mirror case. FirstObservedAt stores the timestamp of entry into either waiting state.

Initialise State to NeedsRelease and FirstObservedAt empty. Permission true with both inputs false selects Ready. A held input at startup cannot arm the model, and an already-held pair cannot become Active merely because the programme has started.

Ready remains Ready while both inputs are false. If only LeftInput becomes true, select WaitingLeft and record the current timestamp. If only RightInput becomes true, select WaitingRight. If both are true, select Active and clear the waiting timestamp.

The state itself carries the relevant release and first-input history. No output holding branch is needed to pretend that a previous AcceptedRequest proves a new attempt is eligible.

02

Evaluate a waiting attempt in a fixed order

In either waiting state, first handle both inputs becoming false: select Ready and clear the timestamp. This abandons the attempted activation and establishes a newly observed complete release.

Otherwise, if the input that was observed first has become false, select Rejected. For example, WaitingLeft with LeftInput false and RightInput true is a handover between inputs, not a valid completion of the original attempt.

Next compare current time minus FirstObservedAt with 500. If elapsed time is at least 500 ms, select Rejected before considering whether both inputs are true. This order matters when the second input arrives after a long gap between evaluations.

Only with the original input still true and elapsed time below 500 may an observation of both inputs true select Active. If the second input is still false, retain the waiting state and the original timestamp.

In Rejected, keep AcceptedRequest false until both inputs are observed false with Permission true. That observation selects Ready. Releasing only one input, waiting longer or returning to both true cannot release rejection.

Call the diagnostic AttemptRejected rather than treating it as proof that someone intentionally defeated a control. A late or inconsistent supplied sequence establishes a model result; it does not establish a person’s behaviour or the unique cause of a physical signal.

Hold the accepted request only for the current pair

In Active, both inputs true keeps the state Active. Releasing either input makes AcceptedRequest false at that evaluation. If both are false, select Ready. If one remains true, select NeedsRelease.

NeedsRelease ignores any combination containing a true input. It only becomes Ready when both inputs are observed false with Permission true. Therefore one input held true while the other is repeatedly released and pressed cannot create another accepted attempt.

Permission false has priority over every state. Select NeedsRelease, clear the timestamp and make AcceptedRequest false. Even if both inputs are false during the permission interruption, do not arm until an eligible evaluation observes their complete release after permission returns.

An unexpected state value also recovers to NeedsRelease and reports InvalidStateDetected for that evaluation. It cannot accept a request on the same evaluation. The subsequent release requirement gives the model a defined starting point again.

The conveyor restart exercise uses another observed-release rule. Compare the two contracts by the conditions required before a new request is accepted.

03

Why an XOR-driven TON can miss a late arrival

Consider a simple timer input of LeftInput XOR RightInput. It is true while exactly one input is true and false while both are true. If the second input arrives late, calling the timer with false can reset the delay before later logic examines whether the original waiting interval was already overdue.

The CODESYS TON documentation describes its falling input edge resetting the delay counter. That behaviour is appropriate for an on-delay timer; it does not automatically preserve the timing history needed by every event-window application.

Use a concrete sparse trace. At time 10, only LeftInput is true. The next observation is at time 610, with both inputs true. Six hundred milliseconds have elapsed from the first observation, so this exercise must reject the attempt even though there was no evaluation exactly at the deadline.

The retained FirstObservedAt value makes that comparison possible. In the revised rule, the deadline is checked before a second input can complete the attempt. A timer reset caused by the new input combination cannot erase the stored origin.

This is a software counterexample, not a claim that all native two-hand instructions have the flaw. The manufacturer instruction cited earlier has its own defined implementation and additional inputs. Test the code actually being taught rather than reasoning only from a familiar rung shape.

A structured-text-style decision outline

The following is language-neutral pseudocode for the virtual model. State names, timestamp storage and the valid-state set are abstract helpers. It is not a declaration of native safety-instruction syntax or a programme for a physical press.

IF NOT Permission THEN
    State := NeedsRelease;
    FirstObservedAt := EMPTY;
ELSIF State NOT IN ValidStates THEN
    State := NeedsRelease;
    FirstObservedAt := EMPTY;
    InvalidStateDetected := TRUE;
ELSIF State = NeedsRelease OR State = Rejected THEN
    IF NOT LeftInput AND NOT RightInput THEN
        State := Ready;
        FirstObservedAt := EMPTY;
    END_IF;
ELSIF State = Ready THEN
    IF LeftInput AND RightInput THEN
        State := Active;
    ELSIF LeftInput THEN
        State := WaitingLeft;
        FirstObservedAt := CurrentTimeMs;
    ELSIF RightInput THEN
        State := WaitingRight;
        FirstObservedAt := CurrentTimeMs;
    END_IF;
ELSIF State = WaitingLeft OR State = WaitingRight THEN
    EvaluateReleaseThenDeadlineThenSecondInput();
ELSIF State = Active THEN
    IF NOT LeftInput AND NOT RightInput THEN
        State := Ready;
    ELSIF NOT LeftInput OR NOT RightInput THEN
        State := NeedsRelease;
    END_IF;
END_IF;

AcceptedRequest := Permission AND State = Active
                   AND LeftInput AND RightInput;

Clear InvalidStateDetected at the start of every evaluation. The waiting helper follows the exact priority described above. Clear FirstObservedAt whenever a waiting state is left, so it cannot be mistaken for the origin of a later attempt.

Process the state present at the beginning of the evaluation once. Selecting Ready from NeedsRelease does not also accept an input in a second pass. Decode AcceptedRequest only after the decision, with one writer for that output.

Follow an accepted attempt and a failed repeat

Start with Permission true and State NeedsRelease. All times are supplied observations. The second input in the first attempt arrives 499 ms after the first, which meets this page’s strict less-than-500 rule.

At 800, both inputs are true but the previous attempt was invalidated by release of only one input. The complete release at 900 is what permits the later accepted attempt. A current-value AND expression cannot distinguish those histories.

Mirror the first attempt by observing RightInput first. The same timing and release rules must hold. A model that accepts left-first input but mishandles right-first input has not implemented a symmetric two-input contract.

04

Test the exact boundary and interrupted permission

From Ready, observe one input at time 10. Test second-input observations at 509, 510 and 511 in separate fresh runs. Their elapsed intervals are 499, 500 and 501 ms. The expected results are Active, Rejected and Rejected respectively.

Repeat with the next observation at 610 and no intermediate evaluation. It must still reject. Then test both inputs released at the deadline: the release branch selects Ready rather than retaining an unsuccessful attempt. That priority is deliberately different from accepting both inputs at the deadline.

While Active, set Permission false with both inputs held. AcceptedRequest becomes false and State becomes NeedsRelease. Restore Permission with both still held: the state remains NeedsRelease. Only an observed complete release can make the next attempt eligible.

Also interrupt permission while WaitingLeft and WaitingRight. The saved timestamp is cleared. Restoration cannot continue the old waiting interval, and it cannot accept the already-held first input as if a new attempt had been armed.

Test a swap from left-only to right-only without an observed both-released combination. WaitingLeft must reject that handover. Run the mirrored case as well. The state machine tracks the original attempt rather than resetting its clock whenever a different single input appears.

Make the limits of sampled evidence visible

A programme sees observations at its evaluation times. Two inputs that changed between those times may first appear true together. This model accepts that pair after Ready, but it does not measure their physical activation separation.

A release and re-press occurring entirely between observations may also be invisible. The lesson therefore verifies behaviour for supplied input traces. It does not establish a maximum physical response time or prove detection of every real-world event.

Log the previous state, current inputs, Permission, FirstObservedAt, calculated elapsed interval and resulting state. Distinguish the timestamp of an observed condition from a claim about when a physical contact actually changed.

The flashing-beacon timing exercise and motor-staging lesson offer related examples of sampled timing. The same discipline applies when a display refreshes more slowly than the underlying programme evaluates.

05

Compare ordinary Boolean logic with documented instruction scope

A useful course discussion compares the model’s assumptions with a manufacturer’s documentation without presenting them as equivalent. The Rockwell reference describes button-contact inputs and diagnostic behaviour beyond the two Boolean values used here. Read its scope before deciding which aspects an ordinary exercise represents.

Keep a comparison record with three columns: the documented feature, the observation your model can make, and the evidence it lacks. For this lesson, “both values are true” is observable. Correct installation, contact diversity, physical device response and machinery suitability are not established by that observation.

Likewise, adding a maximum Active duration would only report that a virtual request remained active longer than its configured limit. It would not by itself detect a stuck valve or verify actual stroke completion. Those claims require independent feedback and an appropriate system design.

Avoid using a generic standards homepage as evidence for a specific clause, button spacing or required hardware arrangement. This article makes no such claim. Its value is a precise software contract with a trace that can expose an implementation error.

South African training and portfolio questions

When comparing PLC training in Benoni, Johannesburg, Pretoria, Durban or Cape Town, ask whether the course topic is ordinary sequence programming or machinery functional safety. A city name, a press animation or a two-button example does not establish the latter scope.

Ask the provider to demonstrate the late-arrival trace without an evaluation at the deadline. Then ask for permission loss while both inputs are held. These tests reveal whether timing and rearming are explicit, rather than inferred from a short normal-operation demonstration.

Use the online PLC training guide for delivery questions and the electrician learning guide for related learning scope. Your portfolio can include a state table, the accepted trace, rejected boundary cases and a corrected software defect.

Describe that portfolio item as a disconnected two-input timing model. It is not a commissioned press controller, a machine safety validation or a registered qualification. Keep the claim aligned with what you actually implemented and observed.

Questions learners ask about two-input timing

Is requiring both inputs true enough?

No, not for this contract. It also requires prior complete release and an accepted timing history. The failed repeat at time 800 has both inputs true but remains in NeedsRelease because no complete release occurred after the previous attempt ended.

Why is exactly 500 ms rejected here?

The exercise explicitly chooses an elapsed interval strictly below 500 ms. This makes the boundary test unambiguous. It is a model rule, not a universal interpretation of manufacturer timing specifications or a standards requirement.

Does Rejected prove an input was intentionally held down?

No. It reports that the supplied sequence did not meet the acceptance rule. The model has no evidence about intent and cannot distinguish every possible physical cause behind the values.

Can I use this to operate a press?

This page provides a virtual learning model only. It supplies none of the physical system design or validation needed to justify that use. Keep AcceptedRequest as a programme indicator in the exercise.

06

Continue with execution-order practice

Inspect PLC Simulation Software’s scan-cycle highlighting feature for a related way to study evaluation order. Its PLC timer learning page provides another timing entry point; neither link claims this exact model is a supplied safety instruction or graded project.

Return to the PLC programming examples collection when you can explain why the late pair is rejected, why one-input release invalidates the current attempt and why permission restoration requires a new complete release. Those three requirements should remain visible in both your implementation and your tests.