Start with the strategy — in matrix form
Before touching the panel, read the cause-and-effect strategy — ideally as a matrix, because a matrix is a truth table: at test time the system is proved row by row against it. Prose paragraphs cannot be, and the gaps stay hidden until commissioning.
If anything is unclear, or something you would expect is missing, verify it with the person who asked you to program it — do not fill the gap with an assumption. Then stop and think about method: some panels give one way to do it; on Vigilon you have several, and the rest of this guide is about choosing well.
Sectors: the core programming tool on Vigilon
On Vigilon, the sector is the unit of cause and effect and the most important programming tool on the system. Every device is assigned a sector.
The mechanism is concrete: a device — say a smoke-sounder — is assigned a sector, say sector 2. When it operates, the sector-linking table decides which sectors are actioned. If sector 2 actions sector 2, that device's own sounder activates.
By default every device sits in sector 1, giving a one-out-all-out system: any input triggers every output. It works, but on sector 1 interfaces go quiescent on silence and not on reset. The fix: move the interfaces to sectors 29–32, which go quiescent on reset, then action those sectors on sector 1.
The one-out-all-out build worth starting from
There is an established sector-linking build that gives a clean one-out-all-out system and the building blocks for anything more complex.
Hit template 1 in sector linking. That defaults the page so sector 1 actions sectors 1–28, and sectors 1–32 all action sector 1. The value is the failsafe: an unprogrammed device falls back to sector 1 and still does something safe rather than nothing.
From the sector linking screen at the bottom of the popout:
- Action sector 2, loops 1 to x, on sector 2, loops 1 to x.
- Action sector 32, loops 1 to x, on sector 2, loops 1 to x.
- Assign all devices to sector 2, except interfaces.
- Assign all interfaces to sector 32.
- Set all of it to signal 2.
When I worked in Gent technical support, this feature was one of the improvements I suggested to development.
Here "1 to x" is the panel's loop count — 1–4, 1–6, or a single loop. This is best-practice one-out-all-out, with interfaces correct on reset — extend it into phased and conditional cause and effect without unpicking the foundation.
Quiescent on reset, and the sound-alarms menu
Sectors 29–32 returning to quiescent on reset and blanking a sector in the sound-alarms menu are the same mechanism. Reset behaviour is set in the sound-alarms menu: the default is signal 2 (pressing sound-alarms actions the sector to that signal), and it can be set to 1 or 3, rarely if ever. Set it to blank and the sector actions on neither the sound-alarm nor the silence-alarm button. That is why sectors 29–32 go quiescent on reset: they are blanked, so it doesn't sound them, and therefore doesn't silence them.
Delays and double knock: count the delays first
As soon as delays or double knock enter the picture, the job changes character. Double knock means a second confirming fire is required — two devices in a zone, or two anywhere on the system — before the full effect runs. It stops one detector in alarm from triggering evacuation or plant shutdown, and is why most modern cause and effect is more than one-out-all-out.
The first number to work out is how many delays the strategy needs, because each panel provides 16 delay blocks. More than 16 and you must plan how to distribute them before you program. If it is a VA system on a single panel that needs more delays than the panel can carry, you will need a second panel to run the extra — a design decision with cost and cabling implications, so surface it early.
In practice — on anything with delays or double knock we routinely take an hour, sometimes an evening, to work the scenarios on paper. Sixteen per panel is a hard limit: counting them first tells you whether this is a one-panel or a two-panel job — and that changes the quote and the programme.
The implementation split: 1–2 panels v 3 or more panels
How you deliver double knock depends on how many panels are involved — the most important branch in the method.
One or two panels. Double knock works in practice using the second-fire override in the delay blocks — the "override the delay on occurrence of 2nd fire" option in the delay block itself.
Three or more panels. The delay-block route no longer holds up. You move to zones or groups and drive the response with command builds (below). Because most modern cause and effect needs double-knock override, this is also where the master sectors and delay-block links become largely redundant on a three-panel-plus site.
Keep the two "second fire" overrides separate: the delay-block override (one or two panels) is a different mechanism from the command-build override (the groups route on three or more).
Zones, groups, and the MCP trap
On three-panel-plus sites the choice between zones and groups matters, and I always use groups. The reason is behaviour I have seen on site: only smoke detectors reliably triggered a cause — even with all devices in zone mode selected. That was as I found it around 2008; it may have been fixed since, though I have not verified that and stick with groups.
Common mistake — manual call points programmed in zones are the sharp end of this: they are found not to trigger command builds. A practice observation, not a line from a standard, but a reliable one — and these are exactly the inputs you cannot afford to have fail silently.
The way round it is groups. With inputs in groups, all of them can trigger a command build — by a single fire, or by two fires for double knock. To make this work you switch to all fire events and set the mode to All OS's ("OS" is out-station, the term Gent used for devices in the BS variants before EN 54 standardised on "devices").
Zones still earn their place for the zone diagram, so zone the site accordingly. Groups also save programming where a cause spans more than two zones, and zones doing the same thing can be doubled up.
In practice — in setup, go to zone and set zones 1–128 to mode "all devices / OS" before you download. Do it once, up front, and save going through every zone or group in the comm tool. Miss it and the fire shows as zone 1, or whatever zone the device is programmed to.
Command builds: triggers, actions, and the second fire
A command build is the engine of the groups route: it can be triggered by one fire and overridden by a second fire.
A build can drive a range of actions, including delay blocks, by delay and by signal. Note that when a build actions a delay block, the build's delay time overrides the delay block's own delay — useful for imposing a different delay, or overriding one you want out of the way. Go through the many trigger and action combinations once to see what they can do.
Build from the truth table
Program from the matrix, not around it: build each row to the effect the strategy defines, so at test time the system reads as a truth table to be walked cause by cause, rather than proved by "it makes a noise".
Testing, commissioning and handover are a separate discipline and deserve their own guide; this one is about getting the programming right so that guide has a truth table to work from.
What good cause-and-effect documentation looks like
The deliverable is that matrix — complete, unambiguous, testable, and the thing the next engineer thanks you for in five years' time.
Download the MFD cause-and-effect matrix template: Excel (matrix + verification sheets) · CSV · print-ready PDF.
Matrix sheet:
- Causes down the left, as zones — one row per zone.
- Effect columns across the top, one per zone — cell value E (evacuate), A (alert), or blank (nothing).
- After the zone columns, interface columns — plant, AOV and any other interfaces — cell value X (activate).
- Optional voice-alarm (VA) column where the site has VA.
- Notes column for the delay rules, in this convention: "3 min delay"; "MCP activation overrides delay"; "double knock overrides delay — as per matrix".
Verification sheet (what keeps it a truth table):
- Expected result (from the strategy)
- Tested (date / initials)
- Pass / fail
- Notes and defects
Complex cause and effect — talk to an engineer
There are methods beyond this overview, developed on large Gent networks over the years; this is the approach in outline, not the whole of it.
A note from experience: when a half-finished cause and effect lands with a tight deadline, I usually start again — much to the dismay of whoever is asking. For me it is quicker to re-write than to work out where someone else got to, because where they got to is usually a dead end.
If you are struggling to complete a cause-and-effect strategy — multiple panels, phased evacuation, VA, heavy interface loads — give us a call and we will provide a quotation to assist. Midland Fire Direct designs, programs and commissions Gent Vigilon cause and effect across the UK. See our commissioning and System Integrator services, request a quote, or call 0844 997 0001.
