Your Valve Reports Closed but the Flow Says Otherwise: Limit Switch and Travel Timer Logic

A CIP sequence hangs on step 7. The HMI shows the transfer valve green and closed, the step permissive is satisfied, and yet the downstream flow meter still reads 4 m³/h. The operator calls it a flow meter fault. It isn't. The valve stem moved far enough to make the closed limit switch and then stopped, because the air supply had dropped to 3.5 bar and the actuator couldn't finish against line pressure.

The display wasn't lying about the switch. It was lying about the valve, because someone wired ZSC straight to a green box and called it "Closed".

Two switches give you four states, not two

An on/off valve with both limits fitted — ZSO open, ZSC closed, per the ISA-5.1 instrument identification letters — produces four raw combinations. Only two of them are a resting position:

ZSC	ZSO	What it means
1	0	Seated at the closed stop
0	1	At the open stop
0	0	Mid-travel — or a failed switch, or a broken wire
1	1	Impossible. Wiring fault, miscalibrated switch, or a swapped pair

That third row is the one people get wrong. 0 0 is a valid transient and an invalid steady state. Whether it's normal depends entirely on how long it's been true and whether a command is outstanding. That's the whole job of the travel timer: turning a raw combination into a claim about the valve.

1 1 deserves its own alarm, immediately, with no timer. There is no physical arrangement where a valve is simultaneously fully open and fully closed. When I see it during commissioning it's almost always the open switch bracket set so loose it makes early, or the two field wires landed on swapped input terminals — check the swap first, it's a two-minute test with the valve stroked by hand.

The command is not the feedback, and the solenoid is not the valve

Three separate things get conflated on a lot of screens:

1. The SCADA/PLC output to the solenoid (XV101.CmdOpen)
2. The solenoid actually energizing
3. The valve body actually moving

A blown fuse on the output card kills 2 while 1 looks perfect. A sheared actuator coupling kills 3 while 1 and 2 look perfect. Only the limit switches speak for the third one, so the derived state tag must be built from switch inputs, never from the command echoed back. If your HMI faceplate turns green when the command is set, you have built a very expensive lamp test.

The command still matters — it tells you which direction the valve is supposed to be going, which is what makes 0 0 interpretable. Combine them into one derived state tag and resolve it in exactly one place:

Derived state	Condition
Closed	ZSC and not ZSO
Open	ZSO and not ZSC
Opening	Open command, neither switch made, travel timer running
Closing	Close command, neither switch made, travel timer running
FaultTimeout	Travel timer expired without reaching the commanded limit
FaultDiscrepancy	Both switches made, or a limit lost with no command change
Unknown	Comms bad or I/O module fault

Every faceplate, interlock, sequence step, and alarm reads this tag. Rebuilding the same conditions inline in five different places is how a valve ends up green on the overview and faulted on the detail popup.

That last state matters more than it looks: if the valve was open and ZSO drops out with no command anywhere near it, something moved that shouldn't have — a manual handle, a lost air supply on a spring-return, a slipping bracket. Don't fold that into "Closing".

Measure the stroke time before you pick the timeout

The travel timer is a plain IEC 61131-3 TON on the command, and the temptation is to set it to a round 10 seconds for every valve on the plant. Don't. Stroke a valve for real during commissioning, three times in each direction, and write down what you measure.

Two things fall out of that exercise. First, open and close times are usually different — a spring-return valve slams closed in under a second and takes three to open against the spring; a double-acting actuator on a big butterfly may take 12 seconds each way. One shared timeout for both directions either nuisance-trips the fast one or hides a fault on the slow one, so use two timers.

Second, the margin. I set the timeout at roughly twice the measured worst case, with a floor of about two seconds so short strokes aren't hair-triggered. Twice sounds generous, and it is deliberately — travel time varies with line pressure, air header pressure, and temperature, and a timeout tight enough to catch a marginally slow valve will also fire on a cold Monday morning when the instrument air compressor is still catching up. Catching gradual degradation is a job for trending, not for the trip.

Trend the actual travel time — it's free diagnostics

This is the part most systems skip, and it's the highest-value tag on the valve. Latch the elapsed time from command to limit-made into an analog tag on every stroke:

• XV101.LastOpenTime — seconds from open command to ZSO
• XV101.LastCloseTime — seconds from close command to ZSC

Historize both with a small deadband. A valve that opened in 2.1 s at handover and now takes 3.4 s has packing friction building, an air line partially blocked, or a positioner losing supply. The step change when a technician overtightens the packing after a leak repair is unmistakable on a trend, and you get it months before the valve fails to make its limit at all. This is the same logic behind partial-stroke testing on IEC 61511 shutdown valves, minus the cost — you're just recording what a stroke already tells you.

One caveat: only stamp the time on strokes that actually completed from the opposite limit. A valve that was already half open because it was mid-travel when the command flipped gives you a meaninglessly short number that pollutes the trend.

Don't alarm during transit

The discrepancy alarm has to be gated on the travel timer, or every single stroke of every valve generates a brief "position discrepancy" while the stem is between the stops. Do that across 200 valves and you have manufactured an alarm flood out of nothing — exactly the sort of nuisance load ISA-18.2 rationalization is meant to strip out.

The rule that works:

• While the travel timer is running, no discrepancy alarm. The state tag says Opening/Closing and the HMI shows transit.
• On timer expiry without the target limit, raise Valve Failed to Open/Valve Failed to Close — and make it latching. A valve that reaches its limit five seconds late must not self-clear the alarm and erase the evidence; the operator acknowledges and resets it deliberately.
• 1 1 alarms with no timer at all.
• A limit lost with no outstanding command alarms after a short filter (200–500 ms is plenty) to ride through switch bounce.

Name the alarms by failure direction, not generically. "XV101 Position Discrepancy" tells the operator nothing at 3am. "XV101 Failed to Close (travel 8.0 s)" tells them where to walk and what to look at.

When there's only one switch

Plenty of valves come with just ZSC, or nothing at all. Be honest in the model about what you can prove:

• Closed switch only. You can prove closed. You cannot prove open — you can only prove not closed, which after a successful open command and a travel time is usually good enough for a permissive but is not good enough for a safety function.
• No switches. The command is the only "state" you have. Then the valve's real feedback is the process: flow after opening, pressure decay after closing. Build the check on that, with a generous delay, and label it clearly on the HMI as inferred rather than confirmed. Colouring an unproven valve the same green as a proven one is how the CIP-step story at the top of this article starts.

Also worth deciding early: a proximity-style switch that fails open, or a broken field wire, reads exactly like "not made". A common trick on important valves is wiring one limit as normally-open and the other normally-closed, so a wire-off condition produces the impossible 1 1 or an inconsistent pair instead of a plausible-looking 0 0. It costs nothing at wiring time and is nearly impossible to retrofit tidily later.

Before you sign off the valve

• Both switches stroked and confirmed at the physical stops, not just electrically jumpered at the marshalling panel.
• Open and close travel times measured three times each and recorded on the loop sheet.
• Timeouts set per direction from those measurements, not copied from a template.
• 1 1 proven by hand (jumper both inputs) and confirmed to raise an immediate alarm.
• Failed-to-open and failed-to-close proven by closing a manual isolation on the air supply mid-stroke.
• Failed-to-* alarms confirmed latching, and the reset confirmed to require an operator action.
• Transit state visible on the faceplate — and a valve left in transit does not read as either open or closed anywhere on the HMI.
• LastOpenTime / LastCloseTime historizing, with the commissioning value written down as the baseline.

A limit switch proves stem position. It does not prove the seat is tight, and no amount of logic will make it do so — a seat that's been wire-drawn by years of throttling will happily make the closed switch while passing several m³/h. If a closed valve keeps showing downstream flow and the travel time is unchanged from handover, stop debugging the SCADA and go look at the seat.