EPICS Release 3.15 - PowerPoint PPT Presentation

About This Presentation
Title:

EPICS Release 3.15

Description:

Occasionally, a bug is introduced in a new release, however. You should proceed with caution. ... Each new release reflects the introduction of new ideas from ... – PowerPoint PPT presentation

Number of Views:24
Avg rating:3.0/5.0
Slides: 11
Provided by: bobda6
Learn more at: https://epics.anl.gov
Category:
Tags: epics | release

less

Transcript and Presenter's Notes

Title: EPICS Release 3.15


1
EPICS Release 3.15
  • Bob Dalesio
  • May 19, 2000

2
Features for 3.15
  • Support for large arrays - done for rsrv in 3.14
  • Channel access priorities - planned to be done
    for 3.14
  • Portable server replacement of rsrv multi
    thread locks,
  • Remove gdd and use new abstract base class
  • Put confirmation
  • Variable length characters strings
  • Unlimited PV name length - possible in 3.14 with
    small changes
  • Periodic Monitors
  • Replace database link support
  • Beyond extend the channel access protocol to
    support archive data, multidimensional
  • arrays, and statistical data

3
Support for Large Arrays
  • The current limitation on the ability to send
    large arrays is in channel access.
  • The limitation is that any value (array) is
    expected to be sent in 1 packet
  • People have created an image record as a work
    around for passing large arrays
  • This is the item that has been on out list of
    things to do in channel access the longest

4
Variable Length Character Strings, Unlimited Name
Length
  • Currently database fields are limited to 40
    characters.
  • This was a limitation of channel access that has
    been fixed
  • The database is now in need of changing string
    handling to support this
  • Variable length strings would support the ability
    to archive operator comments as the channel
    archiver already supports any type available in
    channel access.
  • Channel name lengths are currently limited to 36
    character. (I hope that no channel access clients
    have placed this number into the code)

5
Portable server replacement of RSRV, replace GDD
with a new data object
  • Currently there are two channel access servers to
    maintain rsrv which serves the EPICS database
    and the portable server which serves all other
    data stores. This creates a problem for
    maintenance.
  • The portable server requires GDD and until
    recently GDD has not been reliable.
  • Now that GDD is reliable, it is still not
    lightweight. In the most common case, EPICS sends
    data along with a time stamp and alarm condition.
    For this case, GDD is about 2x bigger that the
    current approach.
  • The new data object could improve the situation
    for composite data, by providing a mechanism for
    sending composite parameters only when they
    change. This would be made transparent for
    current channel access clients.

6
Synchronized Put w/ Confirmation / Rate Limited
Monitors
  • When an application requires puts to be made to
    all IOCs, there are several factors that make the
    time of the puts uncertain
  • for many puts, the buffer may be flushed from the
    client side in the middle
  • the delay to place the value into the database is
    dependent on the time it takes to scan all
    records and therefore different from IOC to IOC
  • A new mechanism will be provided to place the put
    request into the IOC and state that it will be
    executed later. Execution is either at a certain
    time or when an execute command is received.
    Notification of a missed schedule would be
    important.
  • Currently the database only supports monitor at
    the frequency of the record processing. New
    values are sent to clients when either a deadband
    is exceeded or the alarm condition changes. This
    causes a problem for a large channel access
    client like the archiver. If a channel is being
    archived, the rate to place the values on the
    disk may be set to control disk usage. When this
    rate is slower than the monitor rate, network and
    CPU bandwidth are wasted on the client computer.
    Rate limited monitors in the IOC would prevent
    this. Currently, the archiver has a threshold to
    determine if it should use monitor or caGet.

7
Database and Channel Access Priorities Interwoven
  • Currently, the database supports three
    priorities for each scan mechanism. These are set
    in the process database with a database
    configuration tool. The priorities given to the
    scan tasks are only relative to the given scan
    mechanism. Highest priority is given to record
    processing and then the channel access client
    interface. This limits control over the
    degradation of the system by allowing the
    scanning of some less important records to
    inhibit an important client message (like
    synchronized put or close loop control between
    IOCs.
  • The modification would use the priority field in
    the records to determine if the database scan
    task is to run above high priority channel
    access, above medium priority channel access, or
    above the current priority channel access.

8
Replace Link Support
  • The connection between device support and the
    database now consists of two fields DTYP and
    INP. We are looking to combine this into one
    description which would allow multiple I/O
    addresses to different drivers per record type.
  • To verify addresses at configuration time, a
    supported address type has to be specified.
    Adding these types is currently a difficult task.
    We have worked around this using the _at_ to pass
    non-parsed ascii to the device support layer. The
    new link support will make it simple to add parse
    routines for these addresses.
  • The current interface between the database and
    the device support layer does not support the
    ability to change address fields during
    operation. The device support layer that would
    support this ability now, must always check to
    see if the address has changed and take some
    action. The new support will add entry points to
    device support for before_address_is_changed and
    after_address_is_changed so that the device
    support can clean up old connections and make new
    ones.

9
Some Observations Regarding Release
  • We have been taking between 18 - 24 months
    between releases.
  • Our releases have become more and more robust.
    Occasionally, a bug is introduced in a new
    release, however. You should proceed with
    caution. All releases are made in beta until they
    are fully installed on a major project (read
    APS), and have been running successfully in
    production. Beta releases are intended for use by
    members of the collaboration that are willing to
    help test the new code (or those that are working
    with test stands or absolutely must have the new
    features to meet requirements).
  • The ability to improve this schedule is limited
    by several factors that are not uncommon in the
    world of software development trained manpower
    limitations, the need to support people on the
    existing software tends to fall on the person
    that is most familiar with the code, to install a
    new set of functionality properly requires the
    programmer to fully understand the existing
    implementation.
  • There is hope to fix this situation with the
    addition of some new talent. We have several
    excellent programmers (that have joined this
    meeting) that we hope to have actively working on
    IOC core.

10
Conclusions
  • EPICS has been divided into IOC Core and
    extensions to allow the collaboration to make
    frequent and independent modifications to channel
    access client programs, new record support and
    new device/driver support. This has allowed
    frequent modification of these tools.
  • Modifications to EPICS are always based on the
    input of experts in accelerator physics. It is
    only through their valuable experience that we
    learn how to make useful tools. We are grateful
    for each kind criticism that they are willing to
    share with the community. Their knowledge has
    been gained by years of experience and the
    sharing of this knowledge helps to teach us all
    how to make successful control systems at our
    home institutions.
  • In the first training session, when we first
    talked about what EPICS is, there were many
    slides to describe the collaboration. That is
    because we are building a tool-set that is based
    on our combined knowledge and experience. Each
    new release reflects the introduction of new
    ideas from the people in our community.
Write a Comment
User Comments (0)
About PowerShow.com