Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: PV Mapping Using Java Annotations
From: Mitch McCuiston <mmccuiston@aps.anl.gov>
To: tech-talk@aps.anl.gov
Date: Tue, 11 Jan 2011 11:39:17 -0600
 Hi Gabriele,
Thanks for pointing me towards these projects. Both of them have ideas that are very similar to what I had in mind. Admittedly, I was most interested in mapping the synchrous CA operations and hadn't delved into what the async-put and asynch-get might look like. Although, I imagine you could define the put/get listeners similarly to how you define the monitor callback. For example...

@PV(name="PV1",PVAccessType=WRITE_ASYNCH)
void writeValue(double value);

@PVPutListener(name="PV1")
void doSomething(int status);

@PV(name="PV2",PVAccessType=READ_ASYNCH)
void readValue();

@PVGetListener(name="PV2")
void doSomethingElse(double value);


Thanks,
Mitch



On 01/11/2011 10:08 AM, Carcassi, Gabriele wrote:
Hi Mitch,

You may want to have a look at the work that Simon Ebner presented last
spring:
http://www-arch.iter.org/sites/epics2010/slides/3-Wednesday/AM11-JCA_Ext
ensions.ppt
which I believe goes along the direction that you were describing.

In the area of things on top of JCA/CAJ, you may also want to look at my
work on PVManager which also addresses data rate decoupling and thread
local objects (which is always the case for UIs):
http://pvmanager.sourceforge.net/
Composing objects declaratively is what PVManager is about, and creating
an aggregation operation based on annotations is something that would be
easy to add.

The main problem that I think you'll have with simple pojos is that
get/set are synched operations, while with CA one should really be using
asynch operations. For read what you need is really a machinery that
gives you notifications with a new updated copy. You may use a
PropertyChangeListener to keep to the javabean spec, and be clear on the
thread safety of it all. But the locking policies might be an issue...

Writes, instead, are much more of a problem... I don't think there is
any way you can get support asynch writes within the javabean specs.

Gabriele


-----Original Message-----
From: tech-talk-bounces@aps.anl.gov
[mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Mitch McCuiston
Sent: Monday, January 10, 2011 7:13 PM
To: tech-talk@aps.anl.gov
Subject: PV Mapping Using Java Annotations


   I've been thinking about implementing an annotation based mapping of
Java objects to PVs.  I thought I would ask the community if something
like this already exists before I take it on.  If it doesn't exist,
would anyone find value in this.  The idea is loosely based on how
Hibernate maps Java objects to a relational database, although the
read/write semantics are a little different.  Here is an example.

######################################################
public class EpicsMotor{

      //This will peform a synchronous GET of PV "DLLM" upon invocation
      @PV(name="DLLM", accessType=PVAccessType.READ)
      public double getLowerLimit(){
      ...

      //This will establish a PV monitor for "DRBV" that will call the
method
      //below upon any change in "DRBV"
      @PV(name="DRBV", accessType=PVAccessType.MONITOR)
      public void setDialPosition(double position){
      ...

      //Any call to this method will result in a synchronous PUT
      //to the PV named "S".
      @PV(name="S", accessType=PVAccessType.WRITE)
      public void setSpeed(double position){
      ...

      //This will create a monitor for PV named "RBV" that will call this
method
      //upon any change in "RBV".  In addition, any invocations of this
method will
      //be intercepted and a synchronous PUT to PV "RBV" will occur.
      @PV(name="RBV", accessType=PVAccessType.MONITOR_WRITE)
      public void setPosition(double position){
      ...

}
#######################################################

This would allow someone to instrument an instance of the class above at

runtime and "connect" it to a set of PVs (given a prefix i.e.
"xxx:motor1.").  I feel that this would have the following advantages
over writing raw JCA/CAJ.

1.  This could increase read performance because the POJO essentially
becomes a PV cache.
2.  This cuts down dramatically on the amount of channel managment code
that needs writing.
3.  The little bit of channel management code that is written is
centralized and can be better tested.
4.  This provides a nice way of abstracting a collection of PVs for
easier application development.


Thanks in advance for your help!

Mitch McCuiston
mmccuiston@aps.anl.gov



References:
PV Mapping Using Java Annotations Mitch McCuiston
RE: PV Mapping Using Java Annotations Carcassi, Gabriele

Navigate by Date:
Prev: Re: PV Mapping Using Java Annotations Mitch McCuiston
Next: Re: PV Mapping Using Java Annotations J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: PV Mapping Using Java Annotations Carcassi, Gabriele
Next: Problem using large arrays with Channel Access in EPICS 3.14.12 Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·