Controls Commissioning Drill

Question 1

Two techs check the same mixed-air sensor. One sees 55 °F (12.8 °C) on the graphic and moves on. The other puts a decade box on the input, dials in the resistance that should read 55 °F (12.8 °C), and confirms the controller agrees. Why is only the second one a checkout?

Accepted Answer

A graphic can be right for the wrong reasons — wrong object mapping, wrong range scaling, or swapped wires all report believable numbers. Only a known input at the field end proves the whole chain.. Checkout runs from the field toward the front end, because the field is the ground truth and the graphic is the thing on trial. A point mapped to the wrong object reads plausibly. A transmitter scaled on the wrong range tracks in the right direction and lies about the magnitude. Two swapped wires each report a believable number. None of that shows up from the front end — it shows up when you make something known happen at the device and check whether the controller agrees.

Question 2

Commissioning an AO to a modulating valve actuator, you command 0, 50, and 100 % and go watch the valve. What two things is that three-point command proving?

Accepted Answer

Direction and span — that the valve strokes the right way, and that it sweeps its full travel.. Direction catches the reversed action — an actuator wired or configured for the wrong sense strokes backwards, driving wide open on a 0 % command, and the loop fights itself all season. Span catches the actuator that only sweeps part of its travel because its range setting and the software range disagree. Both are invisible from the front end, and both look like a tuning problem later if you skip this. A drive gets the same three commands, plus a confirmation of rotation direction — once, during checkout, before it matters.

Question 3

A binary input's checkout is complete once you have actuated the real field contact and watched the point change state.

Accepted Answer

False. A state change proves the wiring is continuous and the input is alive. It does not prove the sense is right. A normally-closed contact read as normally-open inverts the whole meaning, so "fan running" annunciates as "fan failed" — and the point still changes state obediently every time you exercise it. You have to know which physical condition you created and confirm that OPEN / CLOSED lands where the sequence expects it, not merely that it moved.

Question 4

You are checking out the exhaust-fan BO from the laptop at the panel. You command it on, and the graphic's exhaust-fan symbol turns green with proof satisfied. What is still unproven? command: EF-1 BO2 → ON graphic: EF-1 running ✓ (proof BI satisfied) observed at the equipment: ?

Accepted Answer

That the load which actually started is the one the schedule names. Outputs landed backwards drive the wrong equipment, and the graphic reports the command, not the machine.. The classic BO catch is the mislabeled or swapped pair: you command the exhaust fan and the supply fan starts, because the two outputs are landed backwards or the panel and the schedule disagree. Note that the proof input does not save you — if the proof BI is landed on the same wrong machine, the pair is self-consistently wrong and the graphic looks perfect. The only thing that settles it is going to the equipment and watching which one spun up.

Question 5

The sequence says a freeze trip shall stop the supply fan, close the outside-air damper, drive the heating valve open, and annunciate an alarm. You trip the freezestat and the freeze point goes to ALARM on the graphic. Is the interlock verified?

Accepted Answer

No. The alarm is one of four promised reactions; the interlock is the relationship, so every programmed response has to be observed.. Proving each point moves is necessary and not sufficient. A sequence is a set of relationships: this condition trips, so those outputs respond. Verifying one means making the triggering condition real and confirming the whole programmed reaction — fan off, damper closed, valve open, alarm annunciated — not confirming that the trigger point merely reads. It is entirely possible for the alarm to annunciate while one of the three output responses was never programmed, and the alarm looks like success.

Question 6

A freezestat is hardwired into the supply-fan starter circuit, and it also lands on a BI so the controller can annunciate the alarm and shut the unit down in software. Here is the test that was run to verify it. Why does this not verify the hardwired trip? action: freezestat tripped by hand at the device BI: FREEZE ALARM (controller saw it) BO: SF-1 → OFF (software dropped the fan) fan: stopped ✓

Accepted Answer

Both paths were live, so the software would have dropped that fan whether or not the hardwired trip was intact. Nothing in the record shows the copper could have stopped it on its own.. A hardwired safety exists for exactly the moments the controller cannot be trusted — a railed sensor, a hung program, a value stuck at a number that looks perfectly reasonable and that nothing downstream knows is wrong. A test with both paths live cannot say anything about the one that matters, because the software drops that fan either way — a jumpered-out contact, a broken wire, a trip landed on the wrong terminal, and this record still reads exactly the same. Prove the copper by taking the software out of the path and leaving it watching: hold the fan commanded on from the controller, trip the freezestat, and confirm the fan drops anyway while the BO still reads ON. That is the whole shape of the arrangement — the controller reports the trip, the wiring performs it. Restore the command and verify the software response as its own step, so the record ends with both paths proven instead of one of them assumed.

Question 7

A point-to-point walk passed every line of the I/O schedule. Which of these failures is it still most likely to have missed?

Accepted Answer

A loop that settles fine when you nudge it but hunts for twenty minutes after a real load step.. The first three are exactly what a walk catches — they are all visible the moment you exercise the point. The fourth is not, because it only appears across real operating swings, and a checkout nudge is not a load step. A walk proves a point moved once; it does not prove the loop holds setpoint at three in the morning, that lead/lag actually rotated on schedule, or that staging does not short-cycle on a marginal deadband. That proof lives in trends. A commissioning record that ends at the walk has proven the plumbing — the trends are what prove the sequence.

Question 8

A hot-water plant runs outdoor-air reset. A week of trends shows the supply-water setpoint parked at its design value every day, mild ones included. What does the trend tell you that a spot check at the panel would not?

Accepted Answer

That the reset is not executing at all — a single reading on any one day looks identical to a reset that never moves.. A snapshot cannot distinguish "correct for today's conditions" from "stuck." Design value on a design day is the right answer; design value on a mild day is a failure — and the two look the same in a single reading. Only the record across changing conditions separates them. The usual causes are mundane: the reset block was never enabled, its input was never bound, or the schedule's endpoints collapsed onto one value. All three read as a perfectly plausible setpoint at the panel.

Question 9

You set up a trend on a hunting discharge-air loop before leaving Friday, sampling every 1 minute. The controller allocates the log a 600-sample buffer, and it overwrites the oldest sample once full. How many hours of history does it hold before it starts wrapping?

Accepted Answer

10 h. 600 samples × 1 minute = 600 minutes = 10 hours. That is the whole trap: you left it Friday afternoon to catch a weekend behavior and came back Monday to a log whose oldest sample is Sunday night. The buffer did not fail — it did exactly what it was configured to do, and quietly discarded the swings you set it up to capture. Interval and buffer depth trade against each other: a fast interval resolves a hunting loop but buys you very little history, while a slow one spans the weekend and can miss the oscillation entirely. Size the log against the span you need to observe, or use change-of-value so samples are only spent when the point actually moves.

Question 10

A point's checkout is finished once you have confirmed it against the sequence — writing it up and releasing the force can be swept up together at the end of the day.

Accepted Answer

False. The loop is exercise → watch the field device → confirm against the sequence → document it and clear the force, and it closes once per point. Batching the last step turns it into memory work at the end of a long day, which is precisely when a point gets skipped. The stakes are asymmetric, too: an undocumented pass costs you a re-test, but an uncleared force is a live hazard the logic cannot see — the sequence is executing correctly and being ignored. A forced AO holds a heating valve open into a summer coil; a defeated freeze interlock leaves nothing between a cold night and a burst coil.

Question 11

At turnover, what is the actual deliverable of controls functional testing?

Accepted Answer

The completed record — every point, what exercised it, the observed result, pass or fail, corrections noted — plus an issues log for whatever is still open.. The deliverable is not a working building — it is the proof that the building was verified, point by point, with a name and a date on it. Anything still open goes on the issues log so nothing falls through the seam between "commissioned" and "occupied." The second reason the record matters is the next tech: a year from now, when a sensor drifts or a controller gets swapped, whoever is standing at that panel should be able to read what "right" looked like on the day it was proven. That is what turning a system over means — not "it runs," but "here is the proof it runs, and here is how you will know when it stops."

Controls Commissioning Drill Field Drill