A retail mall in the suburbs opened its basement car park with 486 spaces and a single entry barrier. First weekend: 300 cars, 90 minutes of queue, and one security guard permanently living at the gate. The problem was not the barrier — the problem was that nothing upstream of the barrier knew how many cars were actualy inside.
Gate automation looks like a simple on/off job until you think about the edge cases. The loop detector fires when a car arrives; the barrier opens; the car stops halfway through because the driver wants to check the ticket machine; the loop clears and the barrier slams down on the bonnet. A fixed relay circuit cannot tell "car passed" from "car stopped on the loop." A programmable controller can, and it does it with one Up/Down counter and a timer that is far more patient than the average gate.
The Minimum Logic That Changes Everything
Vehicle presence comes from an inductive loop detector — a reliable, cheap device that senses the metal mass above the loop. The detector output is just a digital input to the controller. From there, the logic is: open the barrier when the entry loop detects a vehicle and access is granted; keep it open for a generous grace time; close it only after the vehicle has fully cleared the second (exit-side) loop; never re-close while a car is still inside the gate zone. The SR-12AC-R-B handles this with a few timers, an Up/Down counter for the space count, and relay outputs for the barrier motor and the warning light.
The part that wins the argument with the mall owner is the counter. Every entry increments, every exit decrements, and when the count reaches capacity the controller lights the FULL sign and stops admitting — no guard, no radio, no shouting. At the end of the day the same counter reconciles against the ticket system, and a discrepancy of more than a few spaces means a loop needs tuning, which is exactly the kind of thing you want to know before it becomes a lawsuit.
Add a second entrance and the logic compounds instead of doubling. Each gate runs its own count, and a master controller reconciles the totals so the FULL sign reflects the whole car park, not one entrance. The RS485 port links the gate controllers together with Modbus, and the site manager reads the live occupancy from any one panel — wich beats three phone calls to three booths. When the counts disagree by more than a couple of spaces, flag it; a loop out of tune is cheaper to fix on a Tuesday than during Christmas shopping.
Interlock Details That Keep the Barrier Alive
Barrier motors die from two causes: continuous duty cycling and running against a mechanical stop. Put an On-Delay interlock on the motor output so the barrier cannot be cycled more than once every few seconds — a frustrated driver mashing the button should not melt the motor. Add a stall timeout: if the barrier has not reached its end position (limit switch) within the expected travel time, cut the motor and sound the alarm; a jammed barrier running hot for five minutes is how a gate becomes scrap.
The same counter gives the operator a daily occupancy number to reconcile with the ticket machine — a discrepancy is a loop problem, not a cash problem, and it surfaces early instead of at month-end.
Payment integration is where the compact controller really earns its keep. The ticket machine or the payment kiosk hands over a simple relay contact — "paid, please open" — and the controller treats it as just another input with the same anti-slam timing. Modbus RTU on the RS485 port lets the controller report the count and gate status to the building management system, so the office upstairs knows the car park is 78% full without calling down. That single number settles more arguments than any intercom.
Fire and emergency rules override everything. The fire panel's contact closes, the controller must receive that as the highest priority input, and the barriers open. The barrier must open and stay open on a fire alarm input, and the entry counter must not block the exit flow — a half-empty car park with locked barriers is a liability no operator should ever explain. Wire the fire signal as a hardwired input that forces the barriers open regardless of program state, and let the controller log the event. The logic for daily life can be clever; the logic for an emergency must be dumb and reliable.
Monthly pass holders are where the small details make or break the site. A pass reader gives a pulse at the barrier; the controller must remember that this vehicle is entitled, open promptly, and log the entry with the time and count. The annoying edge case: a pass holder enters, then backs out without passing the exit loop — the count is wrong and the barrier has already closed. The fix is a reverse-entry rule: if the entry loop clears in the wrong order, decrement the count and log an anomaly. It is two function blocks, and it is exactly the kind of thing a fixed relay panel can never do.
What Nobody Budgets For
The cheapest component in the whole system is the logic, and it is the one that gets reused. Put the gate logic on a controller that also runs the car park lighting schedule or the basement ventilation fans, and the hardware cost of the automation becomes almost invisible. A control cabinet with one xLogic CPU, three relays and a terminal block is easier to maintain than three dedicated boards from three vendors, and when the mall expands to a second entrance you clone the program instead of buying another specialist panel.
Loop detectors, barriers and counters are commodity hardware. The thinking that ties them together is not — and that is precisely the job a programmable relay was built for. Next time you sit in a queue at a mall gate, count the cars ahead and imagine the control panel behind the wall. It is probably a lot simpler than the queue suggests.
