Re: Goals for next phase of epcics-pvdata

[Marty K. <mrk...@co...>]

On 10/30/2012 02:08 PM, dav...@di... wrote:
> We are having a planning meeting, hopefully this week, to discuss our contribution to the next charter in light of the BNL meeting. But in the interim I think my goals would be the following:
>
> My first goal for the next charter is to take a fresh look at the V4 IOC. I don't want to rush into implementing a V4 IOC that's more or less the same as the V3 IOC but with structured data and with pvAccess replacing channel access. I need to make sure that if we're going to provide resource during the next charter it's going towards something that Diamond needs and that we can't do already. To do this I need to spend some time on more detailed requirements, particularly in relation to area detector, and probably try prototyping some stuff.
>
> Actual goals for Diamond in rough order of importance/urgency.
>
> 1. To be able to run an areaDetector driver on one machine, and an areaDetector plugin on another machine, and transfer the NDArrays between the two using EPICS V4 monitors.
> 2. A V4 IOC which when used with area detector makes life easier for our beamline control engineers (this is obviously completely vague, but I'll explain below).
> 3. A pvAccess gui tool.

I will let Bob confirm but I think 1) and 2) mesh with Bob's highest 
priority for the next phase.
I also want very much for these goals to be achieved.

I maintain that the goals I listed are complementary with these goals.

For3) the swtshell that comes with pvIOCJava is mainly a pvAccess gui tool.
It can be used as part of the javaIOC process but most features also 
work remotely.
I use it both ways for debugging.

I do NOT consider swshell a finished product.
But it has the functionality I think is needed for a gui tool for pvAccess.

I would like someone to  re-implement it.
1) use whatever language and GUI platform is appropriate.
2) Make it look nice.
3) Make it only remote.
4) BUT keep the basic features.

Marty


> 1 Is probably the most important application for us. 3 is also very important, but we can wait a little while. I think I'd prefer to address 1 and 2 first, but if we don't have a gui we'll have to make one ourselves.
>
> In terms of 2, our beamline control engineers are finding that they have to an awful lot of work to configure area detector. In particular there is a lot of duplication between the EPICS database, the boot scripts, driver and screens. So a concrete requirement would be to generate the pvAccess endpoints from the driver's parameters (this does not imply that endpoints might not be generated in other ways). More generally we might wish to generate the endpoints from a wider class of objects, e.g. AsynPortDrivers (possibly limited to some subclass, e.g. those whose V3 records are of interrupt or passive scan type). A second requirement would be to allow an IOC's list of pvAccess endpoints to be more dynamic, ideally allowing endpoints to be added and removed at run-time. Applications include determining the endpoints from the parameters of a device (e.g. camera), which  was not on at IOC initialisation or, better, to allow the choice of device to be determined at run-time.
>
> Currently we are not deploying V4 in any way at Diamond and there are no applications that so far that we're likely to use (other than V3Channel which doesn't offer any new functionality that we can't do with V3). Last charter, although we were able to contribute to the design and reliability of pvData and pvAccess and we now have a good base for further development, myself and James spent a lot of time working on things that we  are unlikely to use here, especially the Channel Access Service, and spent a lot of time arguing, mostly futilely.
>
> For the next charter I think a key goal is for the deliverables to include things that address Diamond needs and I'd like our effort here to be directed at these. Also our strategy for V3/V4 interoperability is for V4 clients to talk pvAccess to V4 servers, with channel access being possibly completely replaced by pvAccess in the long term, so we don't really want to be actively working on anything which doesn't fit into that strategy (but we obviously understand other people may have different approaches - we're just not going to put our effort there). This would rule us out working on CAV3, for example.
>
> Regards,
>
> Dave.
>
> -----Original Message-----
> From: Marty Kraimer [mailto:mrk...@co...]
> Sent: 24 October 2012 11:25
> To:epi...@li...
> Subject: Goals for next phase of epcics-pvdata
>
> At last weeks meeting we ran out of time before we discussed goals.
>
> Here is my wish list.
>
> pvAccess:
>
> Full implementation of EasyPVA on both java and C++ Support for CAV3 client in pvAccessCPP (It already exists in pvAccessJava).
>
> pvIOCCPP
>
> There is a section in the latest pvIOCCPP.html that discusses "Future Plans For pvIOCCPP"
> It says:
>
>
> Future Plans For pvIOCCPP
>
> Introduction
>
> What is currently implemented by pvIOCCPP has almost non of the features
> a pvIOC is expected to provide. The documentation for pvIOCJava descibes
> what a full implementation provides.
>
>
> Minimum Features For Channel
>
> The minimum features will allow a full implementation of Channel but
> will require code for each type of functionality desired. In addition
> there will only be a single support for a record instance.
>
> With the minimum features a complete Channel implementation for
> multiChannel is possible.
>
> The minimum set of features is:
>
> pvCopy
>       Creates a PVStructure that contains a copy of an arbitary subset of
> the fields of another top level PVStructure. It can copy data between
> the two and maintains a bitSet that show which fields are changed.
> monitor
>       This provides the ability to monitor changes in the fields of a record.
> PVRecord
>       The features of PVRecord as defined by pvIOCJava with the support
> methods replaced by just method process.
> localChannelProvider
>       localChannelProvider will access data from records using the
> features above. It will implement all channel methods except channelRPC.
>
> Add Support
>
> This phase adds the ability to optionally add support to any field of a
> record. This phase includes the set of basic support that pvIOCJava
> implements. This phase still requires code to create each record and
> register it with channelProvider.
>
> This phase requires:
>
> Support Interface
>       See pvIOCJava for definition.
> Basic support
>       See pvIOCJava for definition.
> other useful support
>       Other support can be added. Looking at what pvIOVJava provides is a
> good starting place.
>
> Add support for using asynDriver
>
> This provides access to all the support provided by asynDriver which is
> huge.
>
> Add database and install and scanning
>
> This provides a database and on-line add and remove records. It still
> requires code to create record instances.
> An xml parser
>
> This provides the ability to create records without writing code.
> Implement portDriver
>
> This is a replacement for the asynManger component of asynDriver. See
> the implementation in pvIOCJava for details.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>