EPICS is thirty-five years old and maintained by people who answer questions. That combination is unusual and it is the ecosystem’s most valuable asset.
The main mailing list. Where you ask, and where core developers answer.
| Archive | epics.anl.gov/tech-talk |
| Subscribe | See epics-controls.org support |
Two things to know:
Search the archive first. It is the largest EPICS troubleshooting corpus in existence — thirty years of “why doesn’t this work?” with answers, well indexed by search engines. Your question is probably already answered, often by the person who wrote the code.
When you do post, post well. Include:
.db and st.cmd fragmentsdbpr <record> 4 output for the record in questionA well-formed question usually gets a useful answer within hours. A vague one gets asked to clarify, which costs everyone a day.
core-talk is the developers’ list, for Base internals and development discussion. Read it if you’re contributing to Base; don’t ask usage questions there.
Issues and discussions on the relevant repository are increasingly where project-specific conversation happens — particularly for Phoebus, epics-containers, Bluesky, and the Archiver Appliance.
For a question about one project, its GitHub issues are often better than tech-talk. For a question about EPICS in general, tech-talk.
| Event | |
|---|---|
| EPICS Collaboration Meetings | Roughly twice a year, rotating between regions. Talks, tutorials, and the place where cross-facility work gets agreed. Slides are published. |
| Codeathons / Documentathons | Working sessions. The most efficient way to learn from experienced people, and to make a first contribution. |
| ICALEPCS | The broader accelerator and physics controls conference, biennial. Substantial EPICS content, and published proceedings. |
| Regional meetings | Europe, Asia and North America hold their own. |
Even if you can’t attend, the published slides from Collaboration Meetings are one of the best sources on current work — they cover things not yet in any documentation, and they show you what facilities are actually doing rather than what the manuals describe.
| Organisation | Contents |
|---|---|
| epics-base | Base, PVXS, p4p, pvaPy, epicsCoreJava, ci-scripts |
| epics-modules | Support modules: asyn, autosave, calc, motor, modbus, iocStats, and ~60 more |
| epics-extensions | Host tools: ca-gateway, MEDM, EDM, VDCT, StripTool |
| areaDetector | Detector and camera drivers |
| ControlSystemStudio | Phoebus and the Java services |
| ChannelFinder | ChannelFinder, recsync, pvinfo |
| Olog | The electronic logbook |
| epics-containers | Container deployment, ibek, PVI |
| EPICS-synApps | The curated module bundle |
| epics-docs | The documentation source |
| archiver-appliance | The Archiver Appliance |
| caproto · pyepics | Python client libraries |
| bluesky | Bluesky, ophyd, databroker, Tiled |
Facility organisations publishing substantial EPICS work: DiamondLightSource, paulscherrerinstitute, slaclab, NSLS-II, ISISComputingGroup, pcdshub (SLAC LCLS), and ESS on gitlab.esss.lu.se.
Facilities publish far more than they announce. If you need something, look at three or four facility organisations before writing it.
You do not need to be an expert. In rough order of accessibility:
Answer a question on tech-talk. If you solved a problem last week, and someone asks about it this week, you are the best-placed person to answer. This is genuinely valuable and consistently underdone by newer members.
Fix documentation. epics-docs takes pull requests. So does every project’s README. A newcomer knows exactly which sentence was confusing, and that knowledge evaporates within six months.
Publish your device support. You wrote a StreamDevice protocol for an instrument. Someone else has that instrument. Put it on GitHub, mention it on tech-talk, and add it to the hardware support directory. The entire ecosystem is built from people who did this.
Report bugs properly. With a reproducer. Maintainers are responsive and mostly volunteering their time; a good bug report is a gift.
Come to a codeathon. Designed for exactly this.
Add to the module directories. The hardware support database is only as good as its submissions.
Questions are welcome, including basic ones. The community remembers that everyone arrives from a physics or engineering background rather than a software one. “How do I talk to this power supply?” is a normal question, not a burden.
People share freely. Protocol files, database templates, screens, configurations — ask and you’ll usually be given. This is a small field where everyone is solving the same problems.
Facility context matters. “How do you deploy IOCs?” gets six different answers because there are six reasonable approaches. Saying which facility you’re at, or what constraints you’re under, gets you a relevant answer instead of a survey.
Old code is not necessarily abandoned. A module with no commits in four years may be finished. Check the issues, not just the commit date, and ask on tech-talk if it matters.
Version numbers are per-module and unrelated. Nobody can tell you “the EPICS 2026 stack”. Compatible sets exist by testing — which is what synApps is for.
| Question | Where |
|---|---|
| “Why doesn’t this work?” | tech-talk, after searching the archive |
| “Is there a module for this device?” | The hardware support directory, then tech-talk |
| A bug in a specific project | That project’s GitHub issues |
| Base internals or development | core-talk |
| “How do other facilities do X?” | tech-talk, or Collaboration Meeting slides |
| “How does my facility do X?” | Your colleagues. This is the most site-specific knowledge there is, and none of it is on the internet. |
| Something in this guide is wrong | Issues here |