1. EPICS Base R3.14.11 and beyond Andrew Johnson Computer Scientist, AES Controls Group

2. 2 EPICS Release Process When enough new features are ready, we create a pre-release version –R3.14.11-pre1 was published on 2009-07-20 –Announced on the core-talk mailing list –Developers and other interested parties run tests against this –Bugs are discovered and fixed After 1-2 weeks we create either another pre-release or a Release Candidate version –R3.14.11-RC1 could be published on 2009-08-03 –Subjective decision, depending on how many bugs were found –Announced on the tech-talk mailing list –All EPICS users are invited to test this version If no substantial bugs found after 1 week, we create a final release version –R3.14.11 could be released as early as 2009-08-10 –Updates to the documentation may continue after the release

3. 3 What’s New in R3.14.11 Records may define aliases for themselves –Multiple names for the same record –Useful when making changes to an existing control system, especially when changing the naming convention –The canonical name can be discovered by reading the.NAME field Modifications to help support redundant IOCs –Several new initHook states Provide notification when pausing and restarting a redundant IOC –New PINI values RUN, RUNNING, PAUSE and PAUSED Process all records thus marked at appropriate time Implemented using new initHook states

4. 4 What’s New cont. A new API has need added to the General Time subsystem –Allows an Interrupt Service Routine to request timestamps from the most recently used current time provider or event time provider Only allowed if the time provider registers a suitable routine Various improvements to the Perl CA library –Flush pending CA operations properly at exit –Pick a better data type to use for put operations Added some support for dynamic loading of components at runtime –Unix-like operating systems only (not Win32) –Tested for subroutine record subroutines and sequence programs

5. 5 What’s New cont. New CA monitor event type DBE_PROPERTY –Intended to allow CA clients to be notified when properties/attributes of a PV other than its value, status and timestamp are changed –For example when a new choice is added to the possible states of an mbbi/mbbo record (enumerated type) –Currently most CA clients that fetch these properties/attributes do so once at connection time and never afterwards They should be changed to subscribe for changes to them –Only the mbbi & mbbo records currently generate DBE_PROPERTY events, other records will do so in the R3.15 series

6. 6 What’s New cont. Long string support –Can now access link and DBF_STRING fields > 40 characters long as an array of characters through CA –Requires the CA client to understand and expect this behavior –The text widgets in MEDM and EDM have supported long strings using arrays of characters like this for many years –Enabled by appending a $ suffix to the field name (after the dot): MyString.VAL$ MyString.$ MyRecord.INP$ –The caget/caput/camonitor tools now support long strings, using a -S option

7. 7 Beyond R3.14.11 The R3.15 CVS already contains some work –Some build system changes to increase layout flexibility –Ability to tunnel CA traffic through SSH CA traffic can be sent through a single TCP socket, no UDP needed –C++ String API (abstract interface, some implementations) Permits multiple string implementations to be used together safely Eventually add variable length string fields to the database –All DBD file processing will be done using Perl at compile-time Removing the IOC’s DBD file parser Simplifies the task of writing say an XML parser for DB files

8. 8 Beyond R3.14.11 cont. Plan to add more field modifiers to PV names, possibilities include –Array offsets (sub-array) MyWaveform.VAL[300] –Fetching multiple fields at once atomically MyCalc.VAL,A,B,C –Access to fields comprising structures MyRecord.TIME.SECS

9. 9 Beyond R3.14.11 cont. With long strings now available, planning to use the internet standard JSON (JavaScript Object Notation) to encode data and field modifiers –Changes to the CA library and protocol need Jeff Hill’s time and effort to implement them –Using JSON avoids having to change the network protocol Backwards compatibility with older versions of the CA library Using JSON for field modifiers: SomeRecord.TIME{”format”:”%Y-%m-%d”} ADC.VAL{”monitor”:{”deadband”:0.5,”maxrate”:10}} Atomic multi-value I/O operations caput 'MyInstrument' '{”CMD”:”move”,”DEST”:100}' caget 'Sema4.OWNR{”put”:{”TAKE”:”ANJ”,”WDOG”:30}}' Sema4.OWNR ANJ