The catalogue. Every significant piece of the EPICS ecosystem, what it does, who maintains it, and where to get it.
How to use this section: don’t read it top to bottom. Skim this index once so the names become familiar, then come back when you have a specific problem. Nobody deploys all of this — a small beamline runs Base, asyn, StreamDevice, autosave and Phoebus, and that’s a complete control system.
| Organisation | What’s there |
|---|---|
| github.com/epics-base | Base, PVXS, p4p, pvaPy, epicsCoreJava, ci-scripts — core, maintained by the core developers |
| github.com/epics-modules | Support modules: asyn, autosave, calc, motor, modbus, iocStats, sscan, busy, and ~60 more |
| github.com/epics-extensions | Host-side tools: ca-gateway, MEDM, EDM, VDCT, StripTool |
| github.com/areaDetector | Detector and camera drivers — its own organisation, that’s how many there are |
| github.com/ControlSystemStudio | Phoebus and the Java services (archiver, alarm, save/restore, scan) |
| github.com/ChannelFinder | ChannelFinder, recsync, pvinfo |
| github.com/Olog | The Olog electronic logbook |
| github.com/epics-containers | Container-based deployment, ibek, PVI |
| github.com/paulscherrerinstitute | StreamDevice, pcaspy, s7plc, and much else from PSI |
| github.com/DiamondLightSource | pythonSoftIOC, aioca, and Diamond’s module ecosystem |
| github.com/slaclab | PyDM, Badger, and SLAC’s stack |
| github.com/EPICS-synApps | synApps — a curated, tested bundle of the above |
| epics-controls.org | The community’s front door, including the module directories |
| Page | Answers the question |
|---|---|
| Base & IOCs | What’s in the core, and what tools come with it? |
| Soft Support Modules | How do I add records, persistence, statistics, calculations? |
| Hardware Support Modules | How do I talk to this specific device? |
| PLCs & Fieldbus | How do I talk to industrial equipment? |
| Motion Control | How do I move something? |
| Detectors & Imaging | How do I take pictures and handle the data rate? |
| Timing Systems | How do things happen at the same time across the facility? |
| Client Libraries | How do I write a program that talks to EPICS? |
| Operator Interfaces | How do I build screens? |
| Web Interfaces | How do I see PVs in a browser? |
| Archiving | How do I know what happened yesterday? |
| Alarms | How does an operator find out something’s wrong? |
| Directory Services | Which IOC serves this PV, and what else is like it? |
| Save & Restore | How do I get back to a known configuration? |
| Electronic Logbooks | Who did what, when, and why? |
| Gateways | How do I cross a network boundary safely? |
| Scanning & Automation | How do I run a sequence without a human? |
| Simulation & Testing | How do I develop without the hardware, and test what I wrote? |
| Scientific Data | How does experiment data get from detector to publication? |
| Physics & Optimisation | How do accelerator physicists drive the machine? |
| Deployment & Operations | How do I run 300 IOCs without going mad? |
| Observability | Is the control system itself healthy? |
You will repeatedly face “there are four tools for this”. General guidance:
Prefer what your facility already runs. The operational cost of a second archiver, or a second GUI toolkit, dwarfs any technical advantage. Being the only person running a tool means being its sole maintainer.
Prefer what’s actively maintained. Check the commit history, not the README. Several widely-installed EPICS tools have not had a commit in years — sometimes because they’re finished, sometimes because they’re abandoned, and the distinction matters when you hit a bug.
Prefer no code. A StreamDevice protocol file beats C device support. A calc record beats a Python script. Declarative configuration survives staff turnover; clever code does not.
Prefer the boring option for anything operational. Novelty is fine in analysis tooling, where a failure costs an afternoon. In the path between an operator and a magnet, choose the thing that has been running somewhere else for ten years.