EPICS Release 3.15 Bob Dalesio May 19, 2000

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

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

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)

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.

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.

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.

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 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.

Some Observations Regarding Release We have been taking between 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.

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.