Project

General

Profile

Incorporating IOCs

Redmine has limited support for concurrent edits. If you try to save your edits and get an error that someone else changed the page, don't give up. Highlight the text you added, copy it to your clip board, cancel the edit to get the new page, re-enter the editor and paste your text.

As of this page's creation date, it is generally accepted that we will officially support EPICS IOCs in our control system. The extent of the support isn't clear but, hopefully, documents like this will spur discussion. This document belongs to the whole department so please add comments, concerns, and corrections. I also encourage everyone to click on the "Watch" link so you get email notifications when this page is edited.

Front-ends

ACNET-based front-ends aren't going away soon; it would be prohibitively expensive to replace every piece of hardware and we need to minimize the impact of operating the accelerator. That being said, there are efforts to upgrade systems to newer versions of VxWorks as well as migrating to Linux using the Erlang-based framework. Programmers preparing to upgrade should seriously consider using EPICS.

What needs to be done?

  • Become proficient and knowledgable about EPICS
    • We have scheduled training at the end of August (tentatively, 26th - 30th).
  • Define (and create?) a build-environment for Fermilab's front-end programmer community
  • Determine how IOCs fit our device model
    • Do we augment our central database to include PVs?
    • How do we manage IOC records?
      • option 1: (proposed by Tim Z)
        • It would be nice to have a tool that we'd use 'one time' to convert IOC records into DABBEL entries if someone delivers us an IOC to integrate
        • Going forward it would be nice to extend D80 & the central database to handle PV unique requirements and then generate all production IOC records out of the central database
        • Jim Patrick mentioned ESS does something along these lines. We can look at their implementation for inspiration.
      • option 2: (?)
  • Find resources listing supported hardware in EPICS so we can start buying compatible, commercial equipment. One of the benefits of EPICS is using their large device driver library.

Central Services and Applications

Applications and services should be mainly isolated from the differences between ACNET and EPICS front-ends. Of course some apps will drill down through the layers to eventually reach specifics, but these would be the exception rather than the rule. Most applications are looking for accelerator data, which both styles of front-ends provide. The top, two tiers of the control system will use DPM, which hides these differences by providing a consistent API to obtain device data. This DPM API will use the yet-to-be-ratified DRF3 format which slightly generalizes the device specification so that PVs fit naturally.

What needs to be done?

  • DPM needs to support channel access so it can communicate with both types of front-ends.
  • DPM needs to support the read-on-change event
    • DRF2 defines this as the 'Q' event
    • IOCs can be asked to only report readings that have changed
  • DPM needs to support settings
  • Finish the DRF3 specification
  • CLIB may need minor tweaks to support DRF3.
  • Services not using CLIB should migrate towards using DPM directly.
    • Synoptic, for example
  • Security schema needs to be discussed and implemented, both for DPM and EPICS applications1.
    • Settings to IOCs need to be logged (even if the settings come from a native EPICS application, unless we block them somehow.)

1 It should be noted that EPICS Applications (i.e. EDM, Control System Studio, etc.) are outside the discussion of this document. We're discussing IOC integration.