Re: BOY widgets and protocols other than Channel Access

["Kasemir, Kay" <kasemirk@ornl.gov>]

Hi:

James, thanks for the quick response!

Yes: BOY, Data Browser, Archive Engine, Alarm Server, EPICS PV Tree, ...
pretty much all use the utility.pv layer which is extensible.

It was, however, implemented to get something that 'works' for EPICS,
and its API is very much like EPICS channels:
* Get a PV
* Add a listener
* Receive updates

The values look remarkably like the EPICS data types:
Values with time stamp, status, display metadata like units,....

The PVManager developed at BNL could be an upgrade that basically adds
the next layer of handling the data.
You can directly ask for values for a bunch of channels,
requesting the average of each channel taken over N seconds,
with notification on some specific thread and so on.
The PVManager is also 'pluggable' and would support pvAccess from the
start,
plus it would support more complex data types.

We're considering moving from the utility.pv layer to the PVManager,
which might simplify the existing code for
BOY, Data Browser, Archive Engine, Alarm Server, ...
But at the same time there's currently no hurry to "fix what's not broken",
plus we have a day job to attend to.

Gabriele and Kunal from BNL have been developing widgets for BOY that
actually use
the PVManager, so the two live data APIs can co-exist while we're
transitioning.

-Kay




On 9/30/11 11:33 , "james.rowland@diamond.ac.uk"
<james.rowland@diamond.ac.uk> wrote:
>Hi
>
>I've made a test connecting BOY to the pvAccess protocol, it's fairly
>straightforward. BOY uses the org . csstudio . utility . pv . IPVFactory
>and org . csstudio . utility . pv . PV interfaces, there are plugins for
>simulated values already in CSS. Some minimal example code is here:
>
>hxxp://epics-pvdata.hg.sourceforge.net/hgweb/epics-pvdata/pvAccessCSSTests
>
>You make a PVFactory which registers a prefix like ipc:// and returns a
>PV when called with createPV(name). The PV object has an IValue
>getValue() method, return an IDoubleValue wrapping a double and some
>metadata. 
>
>James
>
>-----Original Message-----
>From: tech-talk-bounces@aps.anl.gov
>[mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Elliott Wolin
>Sent: 30 September 2011 15:51
>To: tech-talk@aps.anl.gov; Kay-Uwe Kasemir
>Cc: Hovanes Egiyan; David Lawrence; Vardan Gurjyan; carl Timmer
>Subject: BOY widgets and protocols other than Channel Access
>
>Hi,
>
>I'm wondering how flexible BOY and its widgets are concerning
>interprocess communication (IPC) protocols other than Channel Access.
>
>We likely will use BOY for all our EPICS interfaces, and are considering
>using it for our experiment control interfaces as well  (i.e. for our
>"ECS", following LHC nomenclature).   Our experiment control and DAQ
>systems use IPC protocols other than CA, including some home-grown ones
>(e.g. the cMsg publish/subscribe package).
>
>Can BOY accept IPC plugins?  Is CA implemented as a plugin or something
>analogous?  Does BOY use a generic interface to connect to IPC packages
>that we can implement ourselves using our other IPC packages?  Or is CA
>hard-wired in and difficult to disentangle from the core BOY code?
>
>Any information and especially suggestions on how to proceed will be
>appreciated.
>
>Thanks,
>
>-- 
>
>				Sincerely,
>					Elliott
> 
>
>==========================================================================
>======
>
>
> Those raised in a morally relative or neutral environment will hold
>		    no truths to be self-evident.
>				   
>
>Elliott Wolin
>Staff Physicist, Jefferson Lab
>12000 Jefferson Ave
>Suite 8 MS 12A1
>Newport News, VA 23606
>757-269-7365
>
>==========================================================================
>======
>
>
>-- 
>This e-mail and any attachments may contain confidential, copyright and
>or privileged material, and are for the use of the intended addressee
>only. If you are not the intended addressee or an authorised recipient of
>the addressee please notify us of receipt by returning the e-mail and do
>not use, copy, retain, distribute or disclose the information in or
>attached to the e-mail.
>Any opinions expressed within this e-mail are those of the individual and
>not necessarily of Diamond Light Source Ltd.
>Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>attachments are free from viruses and we cannot accept liability for any
>damage which you may sustain as a result of software viruses which may be
>transmitted in or with the message.
>Diamond Light Source Limited (company no. 4375679). Registered in England
>and Wales with its registered office at Diamond House, Harwell Science
>and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> 
>
>
>
>