Fermilab is committing to using EPICS for PIP-II and is also in the beginning stages of a modernization project (ACORN) which plans to gradually replace some existent parts of the control system with EPICS over a 6-7 year time frame.

Other pages in this wiki go into more depth about efforts or implementation details. This Frequently Asked Questions describes the state of integration between EPICS and ACNET.

  1. I hear about bridging software between EPICS and ACNET. Can you tell me more?
    • Support for PVAccess has been added to the Fermilab Controls DPM.
      1. So can I just type a PV name into a parameter page and it'll work?
        • No.
      2. Can I type a PV name into D43 to add to the datalogger?
        • No.
      3. Then what?
        • Create an ACNET device and use our Dabbel/D80 Foreign Device Mapping field to specify the desired PV name. Through ACNET's DPM, this device acts as a conduit to the PV. More details please! Which node should the device be assigned to? Are there restrictions? Does DPM have to be explicitly informed about a new IOC?
  2. Aren't there other bridging techniques I should know about?
    • If you have full access to a version 3.x IOC and don't mind making additions, the EPICS IOC Wrapper for easy integration with acnet is a way to make a set of EPICS PVs more conformant to the standard set of ACNET Device properties. The above methods are recommended, however.
    • An older implementation of an EPICS to ACNET bridge is the ACNET Erlang front-end support for Channel Access. Here again, you create an ACNET device and use our Dabbel/D80 Foreign Device Mapping field to specify the desired PV name. This ACNET device (through its erlang frontend) will then read and set the EPICS PV. This is used for a small set of Nova Far and Near detector devices and for a limited set of devices at CMTS. But this is not the preferred technology going forward.
    • Going the other direction, allowing EPICS IOCs or clients to access ACNET devices: In that dev-ca repository, D. Nicklaus also implemented iocacnet.erl. This acts as a channel access server (running in an erlang front end) with a view into the ACNET device database. It accepts CA device search requests which match the name of an ACNET Device, and then funnels the readings from an ACNET dpmclient back to the requesting CA client. Since demand for this is unknown, it is thus far only a demonstration project with support for a very limited set of reading types.
  3. Someone in our collaboration is contributing an EPICS IOC. Can we run that here?
    • Sure! Any such IOCs should be using at least EPICS Version 7.
  4. What about PV names?
    • Naming convention for PIP-II says a little about PV names.
    • We need to create global (non-PIP-II) PV naming guidelines for the site as a whole.
  5. How can I archive/data-log PVs from my IOC?
    • We don't yet have a version of a native EPICS client archiver (e.g. Archiver Appliance) running here. Soon, one hopes.
      1. Can I archive PVs into the Acnet Dataloggers?
        • If you make your bridge device like above, you should be able to put it into a datalogger. Is this true? Do dataloggers use DPM?
  6. What about EPICS PV Alarms?
    • You are on your own for now.
  7. Can I add PVs to a Fermilab Synoptic display?
    • Only through the ACNET Device name using the device bridge as in Point 1 above.
  8. Didn't we used to be able to read ACNET devices on an EDM GUI?
    • Yes. But support for that has dissolved over the years.
  9. What about accessing ACNET Devices from a Phoebus/CSS/BOY GUI?
    • This could be a project if there is demand for it.