Button Interlock Driver

Overview

Button Interlock provides mutually exclusive button groups for RTI control systems. When a button is selected within a group, the previously selected button is automatically deselected — the same behaviour as radio buttons or source selection switches.

The driver supports 10 independent interlock groups, each containing up to 50 buttons. All states are persistent and survive processor reboots if this option is selected.

How It Works

Each interlock group tracks a single active button. Selecting a new button in a group does three things simultaneously: clears the previous button's feedback, sets the new button's feedback, and updates the group's integer state variable. The driver handles all interlock logic internally — no macros are required.

Pressing a button that is already selected has no effect. The button's inactive state is also driven by the driver, preventing the momentary press-invert that would otherwise occur on an already-active button.

Configuration

Restore State on Startup — when enabled, the driver restores all group states from non-volatile memory when the processor boots. When disabled, all groups start with no button selected. Enabled by default.

Group 01–10 Name — a custom display name for each group. This name is substituted into all function, variable, and event names shown in Integration Designer using dynamic naming. Defaults are "Group 01" through "Group 10". For example, setting Group 01 to "Sources" changes "Group 01 Btn 03" to "Sources Btn 03" throughout the driver. These names are cosmetic only and do not affect tags, sysvars, or runtime behaviour.

System Variables

For each group, one integer variable reports the currently active button number. A value of 0 means no button is selected. Values 1–50 correspond to the button index. This variable can be used in macros with System Variable Test, displayed as button text using the built-in lookup format, or read by other drivers via cross-driver variable subscription.

For each button, two boolean variables provide visual feedback. The first drives the button's reversed state (on/off graphic). The second drives the button's inactive state (prevents the press-invert visual feedback on an already-selected button). Both are written in sync by the driver and bound to the same button via auto-programming.

System Functions

Each button has a dedicated select command with the group and button number embedded as hidden parameters. These are the commands that auto-programming assigns to buttons.

Each group has a clear command that deselects all buttons in that group, setting the active button to 0.

Two utility commands are also available. "Select Button (Dynamic)" takes group and button as visible parameters — useful in macros where the values come from variables or are determined at runtime. Passing button 0 clears the group. "Clear All Groups" resets every group to no selection.

System Events

Each group fires a "Changed" event whenever its active button changes, including when cleared. Use this to trigger macros that respond to selection changes — for example, sending commands to external equipment when a source is selected.

Auto-programming

All button commands, reversed feedback variables, and inactive feedback variables share the same tag per button. When autoprogramming runs, Integration Designer automatically assigns the command to the button press, the reversed boolean to the button's reversed state, and the inactive boolean to the button's inactive state.

Tags use the following fixed naming convention:

Select button: grp01_btn01, grp01_btn02, ... grp01_btn50 Clear group: grp01_clear Groups 02–10 follow the same pattern: grp02_btn01, grp10_btn50, grp05_clear, etc.

To use autoprogramming, create an Integration Designer template with buttons tagged to match. When the driver is added to a project and autoprogramming runs, all matching buttons are fully configured — no manual assignment needed.

Tags are fixed identifiers. Renaming a group in the driver properties changes only the display names shown in Integration Designer, never the tags. This means templates do not need to be updated when groups are renamed.

Persistence

Group states are written to non-volatile memory on the XP processor after each change. The flash write is deferred by 500ms so it never blocks feedback updates to the interfaces. On startup, the driver reads the stored values and restores all boolean and integer variables to their saved state if this is enabled.