Notes from meeting held at APS on 9/03/03.

 

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.

 

John Maclean 9/4/03

 

 

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.

 

Present:

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

 

Agenda:

Conversion to 3.14

            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

 

OS support

            Which OSes should we support? - Discussion

 

Distribution methods

            How can we best deliver/distribute synApps? -Discussion

 

CCD detector support (Bruker, MAR, Roper)

            What should be in synApps? - Discussion

 

Future plans

            What next?

 

 

Report:

Conversion to 3.14

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.

 

 

OS support

            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.

 

Distribution methods

            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.

 

 

Future plans

            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.

 

 

Summary of action items:

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.