I would like to thank everyone who took part in the meeting. I found it extremely valuable. My notes don’t tell me “who said what” during the discussions, so I have tried to summarize the conclusions that we came to. I apologize for not crediting people for their particular ideas.
The meetings purpose was to discuss the status and future of the synApps application package, with particular emphasis given to the OS independent capabilities of EPICS 3.14.
Ned Arnold APS/ASD
Pete Jemian UNICAT
Andrew Johnson APS/ASD
Roger Klaffky APS/AOD
Marty Kraimer APS/ASD
John Maclean APS/AOD
Tim Mooney APS/AOD
Eric Norum APS/ASD
Mark Rivers CARS CAT
Peter Siddons Brookhaven/NSLS
Ron Sluiter APS/AOD
Status - Mark Rivers
Status - Tim Mooney
Status - Peter Siddons
3.14 features for synApps - Eric Norum
MPFOSI - Message Passing Facility Operating System Independent – Marty Kraimer
Discussion. What next?
Asynchronous I/O - Marty Kraimer
Which OSes should we support? - Discussion
How can we best deliver/distribute synApps? -Discussion
CCD detector support (Bruker, MAR, Roper)
What should be in synApps? - Discussion
What next?
Status - Mark Rivers:
Mark presented a talk that described the substantial amount of synApps he and others have already converted to 3.14 and other related work he is doing. Highlights are:
- many non-VME devices are already converted, tested and running on Linux.
- All device independent records now run on Linux
- 6 out of 9 GSECARS VME iocs are running 3.14
- The std module needs additional work to complete
- devLib API not yet complete, needs fppSave, fppRestore analogs
- An application including database and SNL code is under development for control of CCDs and image plates.
Status - Tim Mooney
Tim has done some work on converting his modules to 3.14. He would like to spend more time testing the conversions of his code that he and others have already done.
Following the meeting Tim compiled this list showing the status of std modules.
|
Module |
Status
(if already converted, converters name shown) |
|
scalerRecord |
(Kate Feng) |
|
scanparmRecord |
(Tim Mooney) |
|
tableRecord |
(Tim Mooney) |
|
transformRecord |
(Jens Eden) |
|
vmeRecord |
(Mark Rivers) |
|
gpibRecord |
(Not Converted) |
|
sscanRecord |
(Jens Eden, Tim Mooney) |
|
sCalcoutRecord |
(Tim Mooney) |
|
busyRecord |
(Jens Eden) |
|
swaitRecord |
(Jens Eden) |
|
sseqRecord |
(Tim Mooney) |
|
epidRecord |
(Tim Mooney, Mark Rivers) |
|
genSubRecord |
(Not Converted - probably available elsewhere) |
|
aiCvtDouble |
(Tim Mooney) |
|
basicIoOps |
(Till Straumann) |
|
dbrestore |
(Tim Mooney) |
|
devA32Vme |
(Ron Sluiter, Mark Rivers) |
|
devAiVaroc |
(Not Converted) |
|
drvVarocB |
(Not Converted) |
|
devAoVMI4116 |
(Not Converted - probably available elsewhere) |
|
devBunchClockGen |
(Not Converted - probably available from ASD) |
|
devEpidMpf |
(Mark Rivers) |
|
devEpidSoft |
(Mark Rivers) |
|
devGP307gpib |
(Not Converted) |
|
devHeidVRZ460 |
(Not Converted) |
|
devIK320 |
(Not Converted) |
|
drvIK320 |
(Not Converted) |
|
drvIK320ErrStat |
(Not Converted) |
|
devScaler |
(Kate Feng) |
|
devXxAX301 |
(Not Converted) |
|
devXxHP10895LaserAxis |
(Not Converted) |
|
devXxHeidenhainGpib |
(Not Converted) |
|
devXxKeithleyDMM199 |
(Not Converted) |
|
fGetDateStr |
(Tim Mooney) |
|
fastPID |
(Mark Rivers) |
|
getFilledBuckets |
(Not Converted - probably available from ASD) |
|
hrCtl |
(SNL - should not need conversion) |
|
initHooks |
(Tim Mooney) |
|
iocCheck |
(Not Converted) |
|
kohzuCtl |
(SNL - should not need conversion) |
|
recDynLink |
(Jens Eden) |
|
req_file |
(Tim Mooney) |
|
sCalcPerform |
(Tim Mooney) |
|
sCalcPostfix |
(Tim Mooney) |
|
sCalcoutRecord |
(Tim Mooney) |
|
saveData |
(Tim Mooney) |
|
save_restore |
(Tim Mooney) |
|
stdRegister |
(Mark Rivers) |
|
stdMain |
(Mark Rivers) |
|
stdVxRegister |
(Mark Rivers) |
|
subAve |
(Tim Mooney) |
|
swaitRecord |
(Jens Eden) |
|
xdr_lib |
(EPICS independent) |
|
xdr_stdio |
(EPICS independent) |
|
xia_slit |
(SNL - should not need conversion) |
|
xiahsc |
(SNL - should not need conversion) |
Status - Peter Siddons
NSLS has 14 beamlines running EPICS, 13 of which run VxWorks, 1 runs RTEMS and Linux. Four of these beamlines use binary images, created by Mark, only and do not do any code development.
Peter wants to move away from VxWorks and to adopt RTEMS because of concerns about VxWorks support for small installations.
3.14 features for synApps - Eric Norum
Eric described features that have been included in 3.14.3 to help with synApps applications or at the request of synApps developers.
MPFOSI - Message Passing Facility Operating System Independent – Marty Kraimer
Marty reported that MPROSI was the conversion of mpf to work with the OSes supported by 3.14. It includes mpf and mpf serial.
Marty has had serial and gpib IP modules working on a Linux PC.
Marty wanted to know:
1. Should MPFOSI continue to work on a remote server, and
2. Is IP on Linux interesting?
In answer to 1, it was not generally seen as necessary for MPFOSI to work on a remote server for beamline applications, however there are a lot of remote servers installed on the accelerator.
In answer to 2, it is probably not necessary to use IP modules with serial or GPIB devices because these can more easily be controlled via networked adapters, however there still may be a case for using IP for high throughput analogue IO.
Asynchronous I/O - Marty Kraimer
Asynchronous
Driver Support is a general purpose facility for interfacing device specific
code to low level communication drivers.
Existing
driver support can be replaced by asynchronous driver support. The benefit is
that low level drivers can be shared.
Initial support will include, GPIB, Serial, Vxi11 (includes HP
GPIB LAN servers). In the
future other protocols especially network based.
Which OSes should we support? – Discussion
Linux iocs are here already and look to be a popular choice for small applications, particularly those with networked IO.
There is still and will continue to be a requirement for VME based iocs, for reasons of IO density, specialist IO support, reliability and ruggedness. What OS should be used on these iocs? The choice at present is between RTEMS and VxWorks.
Advantages and disadvantages discussed are summarized in the table below.
|
|
VxWorks |
RTEMS |
Available expertise |
+ |
- |
|
Initial cost |
- |
+ |
|
Maintenance cost |
- |
? (what level is available) |
|
Ubiquity |
+ |
- |
It was felt that for new projects RTEMS could be a valid choice. For established installations there are not, at present, compelling reasons to move from VxWorks. In the future RTEMS may become a viable alternative to VxWorks for established sites if Wind River reduces support for our segment of the market.
It was felt that access to the synApps CVS repository should be given to at least one Brookhaven developer. This would allow RTEMS developers at Brookhaven access to test the latest synApps code with RTEMS.
* Action Item: John – Arrange for Kate Feng to be given read and write access to the repository.
How can we best deliver/distribute synApps? –Discussion
Giving CVS read and write access to Brookhaven and ASD controls staff would allow both these developer communities to access the latest synApps code.
* Action Item: John – Arrange for Andrew, Marty and Eric to be given read and write access to the repository.
Making a nightly snapshot of the repository and placing it in a tar file for access by others will allow others to access the latest synApps code without needing access to the repository.
* Action Item: Andrew, John – Arrange for nightly snapshots of the synApps repository
It was felt that there would be some advantages in making a nightly build available too. This would have the main advantage that anything that broke the build would be seen quickly. It would also mean that it would be simpler for non-developers to pick up, although this would not be tested configurations.
* Action Item: Andrew, John – Arrange for nightly builds of the synApps repository
The question of who should be able to access the snapshots and builds then arose, which brought to light the question of licensing. It was agreed that synApps should be placed under the EPICS open license. This will require the permission of all “substantial” contributors to synApps. Under this license we can place synApps on a publicly accessible web site. Until then, BCDA group will ensure that the latest stable releases of synApps are available on the APS gateway machines. Instructions for accessing the gateway machines will be placed on the BCDA web site.
* Action Item: John – Place instructions for accessing the gateway machines on the BCDA web site.
* Action Item: John – Ensure synApps is available on APS gateway machines
* Action Item: Tim – Give John a list of synApps contributors
* Action Item: John – Obtain permission from synApps contributors for release under BCDA license.
* Action Item: John – When permission has been obtained ensure license is included in distribution etc.
It was felt the std module would benefit from further modularization. This would make it easier for people to get the latest version of, say, a record in std and would help in making more frequent tested, “official” releases easier.
* Action Item: Tim – Partition the std module into smaller modules.
It was agreed that the BCDA web site needs to be improvement and the navigation of it made much simpler. It was also agreed documentation and release notes should have a consistent look and feel. Martys documentation was suggested as a model, it is simple, easy to follow and contains all the pertinent information.
* Action Item: John - make a template HTML file for use in documenting synApps top level applications.
* Action Item: John – Ensure BCDA web site is improved.
* Action Item: John – Publicize documentation standard to developers.
CCD detector support (Bruker, MAR, Roper)
What should be in synApps? - Discussion
There are currently two approaches to CCD detector support available to beamlines:
1. Brian Tiemans PCAS approach
1.2.Marks
Database/SNL approach
Both have advantages. Only Marks approach will be in synApps for the moment.
This is an area that is ripe for further development. No specific action items arose.
What next?
When the action items from the meeting are complete we will have made some big improvements in the organization of synApps development and distribution.
* Action Item: John – Make presentations available on BCDA web site.
No additional action items were generated. Future meetings should be held to discuss specific points and should be open.
Action Item: John – Arrange for Kate Feng to be given read and write access to the repository.
Action Item: John – Arrange for Andrew, Marty and Eric to be given read and write access to the repository.
Action Item: Andrew, John – Arrange for nightly snapshots of the synApps repository
Action Item: Andrew, John – Arrange for nightly builds of the synApps repository
Action Item: John – Place instructions for accessing the gateway machines on the BCDA web site.
Action Item: John – Ensure synApps is available on APS gateway machines
Action Item: Tim – Give John a list of synApps contributors
Action Item: John – Obtain permission from synApps contributors for release under BCDA licence.
Action Item: John – When permission has been obtained ensure license is included in distribution etc.
Action Item: Tim – Partition the std module into smaller modules.
Action Item: John – Ensure BCDA web site is improved.
Action Item: John – Publicize documentation standard to developers.
Action Item: John – Make presentations available on BCDA web site.
*
Action Item: John - make a template HTML file for use in
documenting synApps top level applications.