PLC chiller load interlock: reject the third chiller load

What the interlock has to catch

Two requests damage this plant. The first is a third small load selected onto the 5-ton, which takes that unit past its rating of 2 small BFS loads. The second is a start command sent to the 10-ton while fewer than 3 small loads are routed to it, which is the stated short-cycle condition for that unit. Both look harmless on a routing screen, because the screen shows destinations and the damage is in the totals.

The accept step therefore reads three things before it acts. Each machine's run contact gives the demand. The valve commands, and position switches where the manifold has them, give the routing as built. The chiller status gives the unit's real state, and off, enabled and running are three different states with three different rules. Demand, routing and machine state drift apart during a shift, so the interlock reads all three at the moment it judges a request. That is the same boundary check as validating high and low HMI setpoints before they reach the PLC: judge the request at the edge between screen and controller, and let nothing downstream act on an invalid one.

The larger BFS machine needs one more line in the map. The capacities above are in small-machine loads, and the large machine has no stated equivalent, so the process has to fix that figure before the count can include it.

What you need

• A PLC with discrete I/O for each valve command, each valve position switch where fitted, and a run or demand contact from every BFS machine. Bringing the machines' run signals into the controller lets the count follow real demand instead of screen selections.
• The chillers' remote start contacts, wired to the chiller documentation's remote enable terminals, with run status back into the PLC.
• The capacity map as controller constants: 5-ton maximum 2 small loads; 10-ton maximum 3; 10-ton minimum 3 while enabled; the large machine's equivalent once the process agrees it.
• The chiller maker's minimum loop duration for the enable timer. Chiller makers trace short cycling to system-side conditions, and the compressor short-cycling bulletin for CGAM chillers requires a minimum loop duration of 2 minutes for that line. Use your own unit's published figure.
• An HMI page showing pending, accepted and actual states as three distinct columns, printing a reason with every rejection. If the crew also wants the routing on a screen at the manifold wall, that is a shop-floor screen job, separate from the controls project.
• For scale: 1 ton of refrigeration equals 3.517 kW, so the pair of chillers is about 17.6 kW and 35.2 kW of cooling. The interlock itself counts in small BFS loads, not kilowatts.

Set up the interlock

1. Write the capacity map into the controller as constants, exactly as listed above. Constants belong in the controller, not in tags an HMI project owns.
2. Keep two assignment tables, active and pending; the names are illustrative, and any pair of arrays works. active holds the accepted routing, one entry per machine, and only the accept step writes to it.
3. Bring the inputs in: machine run contacts, valve command bits and position switches, chiller enable and run status.
4. On every operator selection, copy active to pending, apply the requested move to pending, and stop there. No output routine runs in this step, so a half-edited screen never reaches a valve.
5. Count the pending loads, one machine to one load, however many valves feed it. Count distinct machines, not button presses or repeated scans. Add the large machine only with its agreed equivalent.
6. Judge the pending totals against every rule in the map: the 5-ton cap, the 10-ton cap, the 10-ton minimum while it is enabled, and every running machine still served by a chiller allowed to run at that load. Judge the final proposed state, after the move, so a transfer that empties one chiller and overloads the other is caught before either output moves.
7. Reject by changing nothing. Leave active and every valve command bit untouched, send the failed rule and the destination to the HMI, and log both. The reject path performs no output action: no valve pulse, no machine stop, no chiller contact.
8. Accept through a handshake: the panel raises a request bit, the controller answers accept or reject, and only an accept commits pending to active and runs the approved valve and chiller transfer sequence. It is the same handback that lets the PLC catch an HMI recipe load with a handshake tag.
9. Gate each chiller enable with a minimum loop timer preset to the published figure. A start request that arrives early waits, and the timer releases it.

Platforms with a ready-made version of this pattern exist. If your controller runs Studio 5000 Logix Designer, its PlantPAx instruction set includes a Process Interlocks (PINTLK) instruction for process interlocks; the pending table above is the same idea in ordinary rungs.

Routing for each production mix

The production day can run 1, 2, 3 or 4 BFS machines, and each mix has a routing that passes the map. Settle the verdicts once, with the process engineer, and put them in front of the operators:

That last row is where the arithmetic earns its keep. The plant's intent is that both chillers, divided, serve all 4 machines. For the 10-ton to reach its minimum of 3 while carrying 1 small load, the large machine must count as 3 - 1 = 2 small-load equivalents. Take the figure from the chiller selection data and write it into the map; until then, the interlock refuses automatic moves involving the large machine. For the plant-side view of running chillers away from full load, Condition a Chiller Plant Without Cooling the Whole Room is useful background.

Worked example: the third load asks for the 5-ton

Morning: BFS machines M1 and M2 are running, both routed to the 5-ton; M3 is idle; the 10-ton is off. The accepted table reads M1 to the 5-ton and M2 to the 5-ton, so the count on the 5-ton is 2 of 2. The operator selects M3 to the 5-ton for a second batch.

The interlock copies the accepted table to pending and adds the move: M1, M2 and M3 on the 5-ton. Pending count: 2 + 1 = 3 small loads. The limit is 2, and 3 > 2, so the request fails. The HMI shows the destination and the reason, for example '5-ton: 3 of 2 small loads', and no output moves: the valve commands for M1 and M2 hold, M3's valve command holds, and the accepted count stays 2.

Second try: M3 to the 10-ton, with a start request. Pending count on the 10-ton: 1. The minimum for an enabled 10-ton is 3, and 1 < 3, so the enable is refused with '10-ton needs 3 small loads, has 1'.

Third try: the operator routes all three small machines to the 10-ton. Pending count: 3, equal to the unit's stated capacity, so the count passes. The 10-ton last stopped at 10:30:20; the start request arrives at 10:31:00, 40 s later. The example takes the 2-minute minimum loop duration from the bulletin above, so the timer holds the enable for another 120 - 40 = 80 s and releases it at 10:32:20. The 5-ton valves close and the 10-ton valves open in the approved sequence, and the accepted table now reads three machines on the 10-ton, 5-ton idle.

How to check it worked

Three tests, with the process team watching:

1. Reject test. With M1 and M2 on the 5-ton, select M3 to the 5-ton. Expect the reject bit, the reason on the HMI, and identical valve command bits: snapshot the output data table before and after the selection and compare them.
2. Transfer test. Route all three small machines to the 10-ton and enable it. Expect the valves to move in the approved sequence and the enable to fire only after the loop timer releases. Walk the manifold and check each valve's position against the accepted table.
3. Panel test. Take the HMI offline mid-shift and repeat the reject test from a fresh panel or from the controller side. The counts and the reject path keep working, because they live in the PLC; the same split that keeps PLC schedules running when the HMI panel is offline keeps this interlock alive.

Log every acceptance and rejection with a time stamp. After a week of production, the log shows which moves operators attempt most, and those are the pairs worth a dedicated screen button.

Recommendation: Hold every operator request in a pending assignment and validate the whole proposed routing at one accept step before any output moves, with the reject path wired to change nothing. Keep the capacity map as constants in the controller, and gate each chiller enable with the maker's published minimum loop duration. Use the pattern on any routing that operators edit on an HMI while loads are running.

Questions