Auxiliary Telescope Vents#

Abstract

The Vera C. Rubin Auxiliary Telescope (AuxTel) dome vent system is designed to regulate airflow within the dome environment, reducing thermal gradients and supporting stable observing conditions. A system has been designed and constructed to provide automated control and telemetry for the dome vents.

The mechanical system consists of four Greenheck EAD-635 vent gates, each operated by fail-safe spring-return actuators with integrated open and closed limit switches. Electrical control is provided through relay circuits wired in parallel with existing manual switches, enabling both automated and local operation.

A Raspberry Pi 4B equipped with a Sequent Microsystems industrial control HAT serves as the controller, providing 24 VDC digital I/O for actuator control and limit switch monitoring. Control logic and state reporting are handled in software on the Pi, with Modbus used for integrated fan control.

This technical note describes the mechanical layout, electrical and wiring design, control software architecture, and the integration of the system into the Rubin Observatory Control System (OCS). Communication is mediated by a CSC (Component Software Controller) implemented with the Service Abstraction Layer (SAL), supporting telemetry, scripted control, and future system expansion.

Mechanical Layout#

The dome vent system at the Vera C. Rubin Auxiliary Telescope (AuxTel) is designed to regulate airflow through the enclosure in order to reduce thermal gradients that can degrade image quality. The AuxTel building consists of two levels: a lower pier level and an upper dome level where the telescope is housed. The four motorized vent gates are mounted as louvered “windows” in the concrete walls of the pier level, just below the metal-grating floor of the dome level. These vents operate in conjunction with a large exhaust fan installed in the one of the gates to draw warm air out of the lower level, encouraging cooler outside air to flow in. This circulation pattern promotes thermal equalization between the building interior and exterior, particularly during evening cooldown and nighttime observing.

Each vent utilizes a Greenheck EAD-635 adjustable louver, constructed from extruded 6063-T5 aluminum. These louvers feature drainable-style blades designed to channel water away from the building envelope. In the AuxTel configuration, each louver operates over a 35-degree range from fully closed to fully open. The louvers are equipped with bird screens to prevent debris and wildlife ingress.

Each louver is driven by a Belimo AFBUP-S actuator mounted to the damper frame. The actuator provides on/off control and includes a spring-return mechanism that closes the louvers when power is removed. It operates across a voltage range of 24-240 VAC and includes integrated mechanical limit switches for detecting fully open and fully closed positions. The actuator requires approximately 75 seconds to drive the louvers from closed to open under power, and returns to the closed position in less than 20 seconds using spring force. The actuators are mounted on the interior side of the pier wall, with wiring routed through local junction boxes to terminal strips.

For identification purposes, the four vents are numbered 1 through 4, proceeding clockwise from the entrance door. The exhaust fan is installed on vent #2. The actuator on this vent functions normally in both directions; however, the open limit switch is not operable. As a result, the electrical system does not receive a signal when vent #2 reaches its fully open position. This does not affect the mechanical operation of the vent or the fan, and because the actuator is difficult to access, the issue has been classified as low priority for repair.

Wiring#

Observatories in general present a challenging electrical environment due to a combination of factors: inconsistent or noisy utility power, the presence of varied and often highly inductive equipment (such as motors, fans, and dome drives), multiple sources of electrical interference, and significant exposure to outdoor environmental conditions including humidity, dust, temperature variation, wildlife, and so forth. The vent gate system at the Vera C. Rubin Auxiliary Telescope (AuxTel) is designed to operate reliably within this context and incorporates both line-voltage and low-voltage components. Major elements include:

a 240 VAC power distribution branch derived from the main electrical panel,

four Belimo AFBUP-S actuators (one per vent gate),

integrated open and closed limit switches within each actuator,

a Schneider Altivar ATC320U30N4C variable frequency drive (VFD) for fan control,

a Raspberry Pi 4B single-board computer,

and two Sequent Microsystems industrial control HATs providing isolated 24 VDC digital I/O.

Together, these components form the electrical basis for the system’s control, sensing, and actuation functionality.

The components of the vent control system are mounted on an aluminum plate fixed to the wall near vent #2. This plate functions as the primary control panel for the system and currently houses three variable frequency drives (VFDs), of which only one is wired for use with the exhaust fan. It also includes a USR TCP232-410S Modbus-to-Ethernet adapter, a Meanwell 24 VDC power supply, a Raspberry Pi 4B with stacked I/O hats, four DIN-rail relays (one in use), and a set of terminal blocks for both AC and DC circuits. At present, only the wiring for vent #2 is fully installed; the remaining three vents are in a state of partial completion. The panel is mounted in an exposed location, but a metal awning has been installed to provide partial protection from precipitation. A fully enclosed cabinet is planned as a future upgrade to improve environmental protection and simplify long-term maintenance.

A new single-phase 240 VAC branch circuit, connected to breaker 15 in the main observatory electrical panel, supplies power to the control plate. This line terminates at a set of terminal blocks, from which power is routed to the actuator relay, the active VFD, and the 24 VDC supply. The DC supply powers the Pi, its attached control board, and the relay coils used for switching the actuator circuit. Low-voltage control wiring is routed separately from AC lines to reduce electrical noise and improve safety. The wiring is structured to support modular expansion as the remaining gates are brought online.

The system is equipped with a wall-mounted switch box that provides manual control of the vent actuator via a two-position rotary switch. The switch applies or removes line voltage to the actuator, causing it to open when energized and close via spring return when power is removed. For the vent wired to the automation system, the relay output is connected in parallel with the manual switch, creating a logical OR configuration: applying power from either the manual switch or the control relay will open the actuator. This also means that if the vent is opened manually, it cannot be closed via software control until the manual switch is returned to the off position. Operators should be aware of this interaction when using manual override in conjunction with automated scripts.

The actuators include two built-in mechanical limit switches that indicate when the vent has reached its fully open or fully closed position. These switches are electrically isolated and brought out to labeled terminals within the actuator’s wiring box. Six conductors are used per actuator: two commons (one for open, one for closed) and one signal wire for each of the open, closed, and intermediate (~open, ~closed) positions. For the wired vent, these terminals are connected to the control panel using a length of OLFLEX 110 9G1 cable, which provides nine individually numbered conductors and a green/yellow protective conductor. The six relevant wires were terminated at the limit switch blocks in the actuator wiring box and connected at the panel to isolated digital inputs on the Raspberry Pi I/O board. In practice, only the fully open and fully closed signals are used for software logic. One of the open limit switches (on the fan vent) is known to be non-functional, and its signal is currently unavailable. The actuator limit switches are wired to terminal blocks using a standardized color scheme, shown in the table below.

Table 1 Actuator Limit Switch Wiring#
Terminal	Wire Color	Function
1	Purple	Closed COM
2	Red	Closed
3	White	~Closed
4	Orange	Open COM
5	Brown	~Open
6	Gray	Open

Manual control of the exhaust fan is provided through a standalone project box located near the control panel. This box is connected to the VFD via a dedicated cable and includes two controls: a rotary dial and a two-position switch labeled “START” and “OFF.” A printed label instructs the operator to use the dial to adjust the VFD’s frequency setpoint to 25 Hz. The switch toggles the run command input to the VFD, enabling or disabling fan operation. This manual interface allows the fan to be operated independently of the control computer. If computer control of the fan is desired, the control box must be switched to the OFF position.

The automation controller utilizes a Raspberry Pi 4B, equipped with two stacked Sequent Microsystems I/O HATs: the “Mega Industrial” card and the “16-Input” card. These HATs communicate with the Raspberry Pi via the I²C bus and are assigned distinct stack levels to differentiate their I²C addresses.

Mega Industrial Card: This HAT provides opto-isolated digital outputs, which are used to control the relays actuating the vent gates. In the current configuration, four output channels are designated for vent control, corresponding to channels 1 through 4.

16-Input Card: This HAT offers opto-isolated digital inputs, suitable for monitoring signals ranging from 3V to 24V AC/DC. It’s employed to read the open and closed limit switch statuses from each vent actuator. The configuration assigns specific input channels to each vent’s open and closed limit switches, facilitating precise monitoring.

The table below summarizes the I/O channel assignments for each card.

Channel	Card	Function
1	Mega Industrial (Output)	Vent 1 actuator control
2		Vent 2 actuator control
3		Vent 3 actuator control
4		Vent 4 actuator control
9	Sixteen LV Digital Inputs (Input)	Vent 4 open limit
10		Vent 4 closed limit
11		Vent 3 open limit
12		Vent 3 closed limit
13		Vent 2 open limit
14		Vent 2 closed limit
15		Vent 1 open limit
16		Vent 1 closed limit

Software#

At the observatory system level, Rubin software components communicate using the SAL (Service Abstraction Layer) middleware layer, which transports commands, telemetry, and events via Apache Kafka. Commandable SAL Components (CSCs) run on central control machines (e.g., yagan in the case of the summit) and publish or receive messages over the Kafka network. Observatory scripts interact with CSCs by sending SAL commands and consuming telemetry, forming the primary mechanism for the control system.

The vent control system is managed by the ATBuilding CSC, which serves as the software interface between SAL and the physical control system. The ATBuilding CSC communicates directly with the Raspberry Pi controller via HTTP on port 5000, issuing commands to control the vents and querying the Pi for status updates. The communication protocol used for communication between the Raspberry Pi and CSC closely resembles and reuses code from elsewhere in Rubins EAS infrastructure. This design decouples the SAL layer from the hardware I/O implementation and allows the Raspberry Pi to operate as an independent and reusable control node within the observatory infrastructure.

The vent control software running on the Raspberry Pi is structured around two primary Python classes: Controller and Dispatcher. The Controller class is responsible for direct interaction with the hardware, including reading limit switch states and activating the relay outputs via the Sequent Microsystems I/O HATs. It uses the smbus3 library to communicate with the I²C-based input and output boards. The Dispatcher class handles TCP communication with the ATBuilding CSC, exposing a simple protocol over port 5000 for issuing commands and querying system status. The fan VFD is accessed over Modbus TCP using the pymodbus library.

As is standard practice in Rubin Observatory software, the application is implemented using Python’s asyncio framework to manage concurrent tasks and event-driven I/O. The Dispatcher class on the Raspberry Pi implements a lightweight, line-oriented TCP protocol for communication with the ATBuilding CSC. The protocol is plain text, with each command terminated by a carriage return (\r). Commands are sent as single lines in the format:

command <arg1> <arg2> <arg3> ...

Responses are returned as JSON-encoded strings, one per line, with the following template format:

{
    "command": "<command name>",
    "error": 0 or 1,
    "return_value": <number, optional>,
    "exception_name": "<exception type string>",
    "message": "<optional message>",
    "traceback": "<string>",
}

The return_value field should be expected only for successful responses to commands that return a result. The error field is set to 1 in the case of failure, and exception_name and message are populated with diagnostic details.

The following commands are supported:

Table 2 Supported Commands#
Command	Argument Types
`open_vent_gate`	Four integers (0, 1, 2, or 3, corresponding to the vent number. If controlling a subset of vents, pad the arguments with -1.)
`close_vent_gate`	Four integers (same format as `open_vent_gate`)
`get_fan_drive_max_frequency`	(none)
`reset_extraction_fan_drive`	(none)
`set_extraction_fan_drive_freq`	One float (target frequency in Hz)
`set_extraction_fan_manual_control_mode`	One boolean (`true` or `false`)
`start_extraction_fan`	(none)
`stop_extraction_fan`	(none)
`ping`	(none)

In addition to responses to commands, the Raspberry Pi may asynchronously send JSON-formatted events and telemetry messages at any time. These share the same outer structure as command responses, but use specific command names and populate the data field. These messages map directly to SAL events and telemetry:

Table 3 Asynchronous Messages#
Command	Data Format
`evt_vent_gate_state`	Current state of each vent gate
`evt_extraction_fan_drive_fault_code`	Most recent fault code reported by the fan drive
`evt_extraction_fan_drive_state`	Current fan drive state
`telemetry`	Dictionary with telemetry fields such as `tel_extraction_fan` and `tel_drive_voltage`

These asynchronous messages allow the Pi to push updates in real time, and (attempt to) maintain 1:1 correspondence with the SAL telemetry and event interfaces defined in the XML schema. This approach deviates from the usual policy of ESS device protocols of “don’t speak unless spoken to,” but the extra handling involved appears to be minimal, and has the advantage of significantly reducing the “chattiness” of the protocol.

Version

Source