EPICS Controls 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  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: using areaDetector as a support library only
From: "Ernest L. Williams Jr." <[email protected]>
To: Mark Rivers <[email protected]>
Cc: Tech Talk <[email protected]>
Date: Fri, 18 May 2012 13:55:01 -0700
On 05/18/2012 01:00 PM, Mark Rivers wrote:
areaDetector is rather different from motor.  The motor application (WithAsyn) is almost always used as only a test application, since one generally does not have a very useful IOC if all it does is run motors.

The areaDetector applications on the other hand are what a majority of users actually run.  They typically don't integrate areaDetector into a larger application.  They run a soft IOC that just controls a single detector.  In fact I think most areaDetector users just use the pre-built binaries that I produce, they don't even build it at all.  They certainly can integrate it into a larger application, and some sites do, but it is not typical.
We intend to run multiple detectors in one IOC application process.
In our systems we installed a PCI-based timing hardware (MicroResearch Event Receiver).
A single IOC then will control the EVR and multiple detectors.


For that reason I don't think one test app for all detectors is a good idea, because it will become huge, and generally people want an application for a specific detector.

I think we should stick with building one application per detector.  But it would be nice to be able to isolate the application (which has lots of module dependencies) from the library (which has few dependencies).  It seems to me that either means 2 separate configure/RELEASE files, or commenting out the extra module lines when only building the library and not the application.
I vote for commenting out the sections that build example applications.





If anyone has better ideas please share them!

Thanks,
Mark


-----Original Message-----
From: Bruce Hill [mailto:[email protected]]
Sent: Tuesday, May 15, 2012 11:20 PM
To: Mark Rivers
Cc: Williams Jr., Ernest L.; Tech Talk
Subject: Re: using areaDetector as a support library only

The source files for the apps appear to only consist of one
   *registerRecordDeviceDriver.cpp and one *Main.cpp each.
Could areaDetector be reworked to create one test app to
cover all detectors that aren't commented out in ADApp/Makefile?

That's more along the lines of what the motor module does,
and we could just comment out the build for ADApp/testApp
if we didn't want to build it.   One would still need to modify
configure/RELEASE if all the modules needed for the app weren't
available, but as Ernest noted, we're used to doing that when needed.

I suppose that would mean that if you wanted to build a test app for
only some of the detectors, you'd need to modify the PROD_LIBS
and DBD statements in the testApp/Makefile, but maybe that wouldn't
be a common need.

Actually, I'm still not clear why building an app for each detector
is a problem, so I'd be happy to see it stay as is.

- Bruce

On 05/15/2012 07:59 PM, Mark Rivers wrote:
Re splitting each detector into a lib and an app module,
I don't see the need for that.   One module can build
both the lib and a test app.   Many of our other modules
do this.
I guess the disadvantage is that there is only one configure/RELEASE file, and so one needs to edit that to comment out the other modules if one only wants to build the library.

Mark

________________________________________
From: Bruce Hill [[email protected]]
Sent: Tuesday, May 15, 2012 9:43 PM
To: Ernest L. Williams Jr.
Cc: Mark Rivers; Tech Talk
Subject: Re: using areaDetector as a support library only

Hi Mark,
I like your idea of breaking out the detector's into
separate modules, as it should make it easier for
users who only need one or two detectors.
Probably more work for you, however, so we'd be
happy continuing to just comment out the detector
directories we're not using.

Re splitting each detector into a lib and an app module,
I don't see the need for that.   One module can build
both the lib and a test app.   Many of our other modules
do this.

Regards,
- Bruce

On 05/15/2012 03:13 PM, Ernest L. Williams Jr. wrote:
On 05/15/2012 02:54 PM, Mark Rivers wrote:
Hi Ernest,

The next release of areaDetector will be R1-8.  It will keep the same structure as the current release, and should be out soon.  I am making the final tweaks to a driver for the Photonic Sciences Limited detectors.

For the release after that I will break areaDetector into multiple modules.

areaDetector will contain only the code for ADSrc and pluginSrc.  It will not depend on any other EPICS modules besides base and asyn.

Each detector will be in its own module, e.g. ADProsilica or something like that.  My plan was to make ADProsilica build both the library and the example application.  That means its configure/RELEASE would depend on synApps modules like what you show.  You still might not like that, since you would want the ADProsilica module to also be just a library that you can build into your IOC.

I could break each detector into 2 modules:
ADProsilicaLib - just builds a library, does not depend on any other modules except base and asyn
ADProsilicaApp - builds an example application, depends on other synApps modules
==================================================================
What about instead; one module but two Apps?  Like so,

ADProsilica
ADProsilicaLibApp
ADProsilicaTestApp


Now, you just have one module to maintain,
When the IOC App developer is ready to use your module then we can
comment out the TestApp from the driver build.
Basically, we can follow the way the motor software is packaged.


The problem with that is that areaDetector would then be broken into 29 modules, since there are currently 14 detectors plus the base code.  That's a lot more work for me, since each needs to be separately packaged and released.  But maybe it's the best way to do it.
Again you can have one module with multiple Apps.
Commenting/uncommenting  in the Makefile and "configure/RELEASE"
controls the build.



I'm also sending this to tech-talk, since I know others have expressed similar desires, and I'd like to get comments.

Mark


From: Ernest L. Williams Jr. [mailto:[email protected]]
Sent: Tuesday, May 15, 2012 4:32 PM
To: Mark Rivers
Cc: Williams Jr., Ernest L.
Subject: using areaDetector as a support library only

Hi Mark,

In an effort to reduce dependencies when preparing a shared module such as areaDetector; how to do this?

Here is what we have now:
SNCSEQ=$(EPICS_MODULES)/seq/$(SEQ_MODULE_VERSION)
AUTOSAVE=$(EPICS_MODULES)/autosave/$(AUTOSAVE_MODULE_VERSION)
ASYN=$(EPICS_MODULES)/asyn/$(ASYN_MODULE_VERSION)
SSCAN=$(EPICS_MODULES)/sscan/$(SSCAN_MODULE_VERSION)
CALC=$(EPICS_MODULES)/calc/$(CALC_MODULE_VERSION)
BUSY=$(EPICS_MODULES)/busy/$(BUSY_MODULE_VERSION)
STD=$(EPICS_MODULES)/std/$(STD_MODULE_VERSION)
MCA=$(EPICS_MODULES)/mca/$(MCA_MODULE_VERSION)


I would like to build areaDetector as a support library that is referenced and linked in by an
IOC application.

This means that I would like to select not to build the IOC parts of areaDetector as they depend on such as autosave.
What is the best way to achieve this?
Seems that every driver creates an App via  "ADApp/commonDriverMakefile"

I only want to include those components necessary for the module library.
We will include the other components along with our IOC Application.
What is the cleanest way to do this?

Cheers,
Ernest

--
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025



References:
RE: using areaDetector as a support library only Mark Rivers
Re: using areaDetector as a support library only Ernest L. Williams Jr.
Re: using areaDetector as a support library only Bruce Hill
RE: using areaDetector as a support library only Mark Rivers
Re: using areaDetector as a support library only Bruce Hill
RE: using areaDetector as a support library only Mark Rivers

Navigate by Date:
Prev: Re: using areaDetector as a support library only Andrew Johnson
Next: Re: using areaDetector as a support library only Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: using areaDetector as a support library only Ernest L. Williams Jr.
Next: Re: using areaDetector as a support library only Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
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 ·