Experimental Physics and
Industrial Control System

"Carcassi, Gabriele" <[email protected]> · Fri, 30 Sep 2011 14:32:59 -0400

Expanding what Kay says: we are making sure that the new types pvManager
uses (table, multi-dimensional array, image, statistics, ...) are the
ones that we are defining for pvAccess and that you can also create
these on the client side (e.g. you connect to a 1000 pvs organized in a
table, you are notified on the whole table in the same way that you
would if you took the table across the wire using pvAccess).

On the other hand, you are not limited to produce/consume those types.
pvManager is designed to be type agnostic (just passes objects around),
so that if you have particular applications that require different types
(e.g. JMS message, SNMP, ...), you can still re-use the whole machinery
(queuing, caching, rate throttling, ...).

If you are interested, you can find documentation here:
http://pvmanager.sourceforge.net/
The library is available in the epics maven repository:
http://epics.sourceforge.net/maven2/epics/
In the CSS repository:
http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/cs-studio
the following plugins have SWT and BOY widgets built on top of
pvManager:
org.csstudio.channel.widgets
org.csstudio.channel.opiwidgets
There is going to be a talk in the epics meeting about pvManager, and in
the CSS training Kunal we'll talk about some of the BOY widgets and
applications built on top of it.

Thanks,
Gabriele

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Kasemir, Kay
Sent: Friday, September 30, 2011 1:25 PM
To: [email protected]; [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: BOY widgets and protocols other than Channel Access

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 , "[email protected]"
<[email protected]> 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/pvAccessCSSTe
>sts
>
>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: [email protected]
>[mailto:[email protected]] On Behalf Of Elliott Wolin
>Sent: 30 September 2011 15:51
>To: [email protected]; 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
> 
>
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System