A hardware support module provides in-IOC software to control a specific real-world device or device family.
Official directory: epics-controls.org — Hardware Support — this is the searchable list of hundreds of devices with maintainers and links. Check it before writing anything.
In order:
.proto file → records over generic asyn support → an asynPortDriver subclass in C++ → C device support from scratch.!!! tip “Steps 1–5 before step 6, seriously” The commonest avoidable waste of a new controls engineer’s first month is writing device support that already existed. Twenty minutes of searching is worth it every time.
Detailed pages exist for the big ones:
motor module and its several dozen controller drivers| Device family | Support |
|---|---|
| Pfeiffer, Leybold, Edwards gauge controllers and turbo pumps | Usually StreamDevice protocol files; many published by facilities |
| Agilent/Varian ion pump controllers | StreamDevice; check facility repos |
| MKS gauges and mass-flow controllers | StreamDevice, or Modbus/serial variants |
| Gamma Vacuum SPCe | Published protocols in several facility repos |
| Valve control | Almost always via a PLC — vacuum valve interlocks are protection logic and belong there |
Vacuum is the classic StreamDevice domain: nearly every controller speaks ASCII over RS-232/RS-485, and a .proto file is a couple of hours’ work.
| Family | Notes |
|---|---|
| Danfysik | Widely used in accelerators; StreamDevice or facility-specific drivers |
| TDK-Lambda / Genesys, Delta Elektronika, Kepco | StreamDevice over serial/Ethernet, or Modbus/TCP |
| Bruker, Caen | Vendor protocols; check facility repos |
| Corrector supplies in a fast feedback loop | The feedback is FPGA-based; EPICS handles setpoints and diagnostics only |
| Device | Support |
|---|---|
| Lakeshore 218/224/336/350 controllers | Well-supported; StreamDevice and dedicated modules widely published |
| Cryomech, Sumitomo coldheads | Serial, StreamDevice |
| Cryo plant | Almost always a large PLC/SCADA system; EPICS reads it via OPC UA or Modbus |
| Thermocouples and RTDs | Via a datalogger, PLC analog input, or a dedicated card; conversion via ai record breakpoint tables (LINR) |
| Family | Notes |
|---|---|
| MTCA/AMC digitisers (Struck, IOxOS, CAEN) | Vendor-specific drivers, often facility-maintained; MTCA is the modern standard for fast diagnostics |
| VME boards (Joerger, Hytec, Acromag) | Long-standing modules in epics-modules; the legacy that still runs |
| IndustryPack carriers | ipac |
| CAEN, NI, Measurement Computing USB DAQ | measComp covers Measurement Computing; others vary |
| Beam-charge / current amplifiers | quadEM for four-channel electrometers |
Diagnostics is the least standardised area, because the electronics are usually facility-specific or bespoke:
| Device | Reality |
|---|---|
| BPM electronics (Libera, BPM-FPGA designs) | Vendor or facility drivers; often a thin asyn layer over a register map |
| Beam current monitors (DCCT, ICT) | Analog → ADC → ai records, or vendor digital interface |
| Screens / flags / YAG monitors | Motion (motor) + camera (areaDetector) |
| Beam loss monitors | Digitiser plus threshold logic, with the interlock function in MPS hardware |
| Wire scanners, emittance monitors | Motion + acquisition + a sequencer or scan |
| Layer | Where it lives |
|---|---|
| Fast amplitude/phase regulation | FPGA. Not EPICS. |
| Setpoints, ramps, mode control | EPICS, via the LLRF system’s register interface or a vendor driver |
| Waveform diagnostics | Large waveform records, often over PVA for the metadata |
| Interlocks (arc, reflected power, window temperature) | Hardware, reported into EPICS read-only |
Usually a combination: motion for gap and phase, a PLC for the safety-relevant limits, and a coordination layer — often a sequencer program or a dedicated IOC — implementing the taper/gap/phase relationships and the feed-forward tables that keep the ring’s tune stable as the gap moves.
| Device | Support |
|---|---|
| Monochromators, mirrors, slits | motor, often with coordinated pseudo-motors |
| Piezo fine stages | Vendor drivers over serial/Ethernet |
| Attenuators, filters | Pneumatic actuators via PLC or digital I/O |
| Shutters | PLC — a shutter is protection equipment |
flowchart TD
A["Device speaks a documented<br/>ASCII or simple binary protocol<br/>over serial / TCP?"]
A -->|Yes| B["StreamDevice .proto file<br/>⏱ hours · no compilation"]
A -->|No| C["Modbus / EtherNet-IP / OPC UA / S7?"]
C -->|Yes| D["Existing protocol module<br/>⏱ hours · configuration only"]
C -->|No| E["Vendor C/C++ SDK,<br/>or a register-mapped card?"]
E -->|Yes| F["asynPortDriver subclass in C++<br/>⏱ days-weeks"]
E -->|No| G["Custom hardware,<br/>bus-level access, RTOS target"]
G --> H["C device support + driver<br/>⏱ weeks · needs real EPICS depth"]
Whatever route you take:
epics-modules driver are better teachers than the documentation.asynRecord to explore the protocol before writing anything — send strings from a screen and watch the replies.asynSetTraceMask("PORT",-1,0xff) shows every byte on the wire.