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).
    • UPDATE: Many of us attended the training and we now have enough knowledge of EPICS to start supporting it in our control system as well as know what questions to ask for details we don't understand.
  • 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?
    • UPDATE: Brian and Glenn already have added a "foreign device" field to the database. For the time being, we can use this table to map EPICS PVs to ACNET properties.
    • 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.
    • UPDATE: Jim Patrick provided the pvAccess .jar file, used in Phoebus, to Charlie for use in DPM.
    • UPDATE: Charlie tweaked the DRF parser to accept any name in the property field instead of just ACNET property names. DPM uses the foreign device table to determine whether it's an ACNET or EPICS device. It sends the request to the appropriate, low-level data acquisition protocol. If the device isn't in the database, DPM assumes it's a PV name and tries to access it via EPICS channel access.
    • UPDATE: Glenn is updating DABBEL so devices can be marked as EPICS-related.
  • 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
    • UPDATE: Beau, Charlie, and Rich worked on a setting protocol. Charlie added support for it to DPM. Beau wrote a Python library to support settings. We're temporarily using a "whitelist" to grant a small set of users access to this protocol. The Python client library gets user credentials through the Kerberos ticket. We may be able to use GSSAPI to pass credentials to DPM.
  • 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
    • UPDATE: Beau and Rich wrote libraries for Python and JavaScript clients to access ACNET devices and EPICS PVs.
  • 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.)

Data Request Rates

Using waveform PVs for Fermi data acquisition would limit the number of PVs on a given IOC to two per Fermi device property. One for periodic requests and one for event requests.

This DAQ model has a benefit in using PVAccess over ChannelAccess because PVAccess allows users to destructure a PV while ChannelAccess would require us to create a PV for each waveform subsample we wanted.

Periodic Requests

We should evaluate the performance of IOCs requesting data at high rates, but Bob Delesio suggested that IOCs won't sweat 1kHz. The current consensus is that we should choose a base DAQ frequency and decimate data for the slower user requests. This base frequency shouldn't be chosen arbitrarily as it will determine our resolution and error for time stamps. Controls should consult machine groups for a specification.

We should consider the consequences of the SCAN rate versus waveform rate. A scan rate faster than 1Hz allows us to deliver less than 1000 points for a 1kHz request.

Event Requests

Pierrick recommended having a clock decoder drive the updates of a single waveform PV. This would allow DPM to make an array subselection for the event that a user is interested in without creating a PV for each event.


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.