EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Is anyone building AreaDetector with Sumo?
From: Jeong Han Lee via Tech-talk <[email protected]>
To: Mark Rivers <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Thu, 22 Aug 2019 22:50:22 +0200


On 8/22/19 10:23 PM, Mark Rivers wrote:
  I have to confess one more thing, for the our environment at ESS, we don't need to care about other modules support if they are not dependent upon the source directly when we compile a module. When we start an IOC, we have to define this kind of dependency within startup scripts.

The busy module, for example, is not needed when compiling the PointGrey driver, but it is needed when linking the IOC application.  You say it is only needed when "starting" an IOC, but it seems to me it is needed also when linking the IOC.


Your explanation is much more clean one than I have. Yes, we link the busy module dynamically with the FLIR IOC application. Somehow, my explanation was contaminated by ESS site specific jargon.

  Thank you.

  Han


Mark


-----Original Message-----
From: Jeong Han Lee <[email protected]>
Sent: Thursday, August 22, 2019 2:52 PM
To: Mark Rivers <[email protected]>
Cc: Johnson, Andrew N. <[email protected]>; [email protected]
Subject: Re: Is anyone building AreaDetector with Sumo?

Hi Mark,

On 8/22/19 8:04 PM, Mark Rivers wrote:
Jeong wrote:

         This is not true, and the following is the correct one.

<pre>
    ```
         *  EPICS Base -> asyn -> ADCore <- ADSupport
                                  |
                                  V
            Vendor Lib -> ADPointGrey -> FLIR Camera IOC application
``` </pre>

That is really not correct either.  The FLIR IOC application almost
always also depends on other synApps modules (busy, calc, autosave,
etc.).  Some are optional, but busy, for example, is not.

    Yes, Mark, you are correct, FLIR Camera IOC application needs the busy record. However, this busy dependency will be introduced within "DB record" inside the database and dbd file, not the source codes and compiling process if only we compile the pointGrey. I cannot see any header file dependency upon .d files within the pointGrey. In addition, the version which I am saying is R2-7. Please correct me if I am wrong.

    I have to confess one more thing, for the our environment at ESS, we don't need to care about other modules support if they are not dependent upon the source directly when we compile a module. When we start an IOC, we have to define this kind of dependency within startup scripts.

    So with your email, I think, Andrew may have the better idea then before.

    HTH,
    Han



I would also like to point out that when one runs "make release" in
the top-level synApps support/ directory above areaDetector it will
correctly update areaDetector/configure/RELEASE_LIBS.local and
RELEASE_PRODS.local to use the versions defined in
synApps/support/configure/RELEASE

For example here are snippets from
areaDetector/configure/RELEASE_LIBS.local and RELEASE_PRODS.local
where ASYN, AREA_DETECTOR, and EPICS_BASE are set to nothing:

RELEASE_LIBS.local

::::::::::::::

#RELEASE Location of external products

# Run "gnumake clean uninstall install" in the application

# top directory each time this file is changed.

# If using Debian packages then the following must be done:

#  SUPPORT should be defined to be the root location of any modules
which should NOT come from the Debian package.

#  Any modules which should come from the Debian package should be
commented out, except for EPICS_BASE.

#  For example to use a newer version of asyn and areaDetector then
define ASYN, AREA_DETECTOR, ADCORE,

#  and ADSUPPORT here.  To use the Debian version of asyn then comment
out ASYN here.

# If you don't want to install into $(TOP) then

# define INSTALL_LOCATION_APP here

#INSTALL_LOCATION_APP=<fullpathname>

# ASYN is needed for base classes

ASYN=

AREA_DETECTOR=

# ADSupport is needed by ADCore plugins

ADSUPPORT=$(AREA_DETECTOR)/ADSupport

# ADCORE for base classes and plugins

ADCORE=$(AREA_DETECTOR)/ADCore

EPICS_BASE=

.

::::::::::::::

RELEASE_PRODS.local

::::::::::::::

#RELEASE Location of external products

# Run "gnumake clean uninstall install" in the application

# top directory each time this file is changed.

# If using Debian packages then the following must be done:

#  SUPPORT should be defined to be the root location of any modules
which should NOT come from the Debian package.

#  Any modules which should come from the Debian package should be
commented out, except for EPICS_BASE.

#  For example to use a newer version of asyn and areaDetector then
define ASYN, AREA_DETECTOR, ADCORE,

#  and ADSUPPORT here, but comment out AUTOSAVE, BUSY, etc.

# If you don't want to install into $(TOP) then

# define INSTALL_LOCATION_APP here

#INSTALL_LOCATION_APP=<fullpathname>

# ASYN is needed for base classes

ASYN=

AREA_DETECTOR=

# ADSupport is needed by ADCore plugins

ADSUPPORT=$(AREA_DETECTOR)/ADSupport

# ADCORE for base classes and plugins

ADCORE=$(AREA_DETECTOR)/ADCore

#AUTOSAVE is needed for save_restore

AUTOSAVE=

.

At the top level of synApps/support I then run "make release".

corvette:~/devel>make release

It then updates RELEASE_LIBS.local and RELEASE_PRODS.local to the
versions in use.

RELEASE_LIBS.local

::::::::::::::

#RELEASE Location of external products

# Run "gnumake clean uninstall install" in the application

# top directory each time this file is changed.

# If using Debian packages then the following must be done:

#  SUPPORT should be defined to be the root location of any modules
which should NOT come from the Debian package.

#  Any modules which should come from the Debian package should be
commented out, except for EPICS_BASE.

#  For example to use a newer version of asyn and areaDetector then
define ASYN, AREA_DETECTOR, ADCORE,

#  and ADSUPPORT here.  To use the Debian version of asyn then comment
out ASYN here.

# If you don't want to install into $(TOP) then

# define INSTALL_LOCATION_APP here

#INSTALL_LOCATION_APP=<fullpathname>

# ASYN is needed for base classes

ASYN=$(SUPPORT)/asyn-4-36

AREA_DETECTOR=$(SUPPORT)/areaDetector-3-7

# ADSupport is needed by ADCore plugins

ADSUPPORT=$(AREA_DETECTOR)/ADSupport

# ADCORE for base classes and plugins

ADCORE=$(AREA_DETECTOR)/ADCore

EPICS_BASE=/corvette/usr/local/epics-devel/base-7.0.3

.

::::::::::::::

RELEASE_PRODS.local

::::::::::::::

#RELEASE Location of external products

# Run "gnumake clean uninstall install" in the application

# top directory each time this file is changed.

# If using Debian packages then the following must be done:

#  SUPPORT should be defined to be the root location of any modules
which should NOT come from the Debian package.

#  Any modules which should come from the Debian package should be
commented out, except for EPICS_BASE.

#  For example to use a newer version of asyn and areaDetector then
define ASYN, AREA_DETECTOR, ADCORE,

#  and ADSUPPORT here, but comment out AUTOSAVE, BUSY, etc.

# If you don't want to install into $(TOP) then

# define INSTALL_LOCATION_APP here

#INSTALL_LOCATION_APP=<fullpathname>

# ASYN is needed for base classes

ASYN=$(SUPPORT)/asyn-4-36

AREA_DETECTOR=$(SUPPORT)/areaDetector-3-7

# ADSupport is needed by ADCore plugins

ADSUPPORT=$(AREA_DETECTOR)/ADSupport

# ADCORE for base classes and plugins

ADCORE=$(AREA_DETECTOR)/ADCore

#AUTOSAVE is needed for save_restore

AUTOSAVE=$(SUPPORT)/autosave-5-10

# BUSY is needed for busy record

BUSY=$(SUPPORT)/busy-1-7-2

# CALC is needed for the sseq record that is used for the reset in
NDStats.template

# and which is loaded into the example IOCs for general purpose use.

# CALC is also needed for scalcout record that SSCAN uses

CALC=$(SUPPORT)/calc-3-7-3

.

Thus in many cases it is not necessary to edit these files in
areaDetector/configure.

Mark

----------------------------------------------------------------------
--

*From:*[email protected] <[email protected]>
on behalf of Jeong Han Lee via Tech-talk <[email protected]>
*Sent:* Wednesday, August 21, 2019 6:00 PM
*To:* Johnson, Andrew N.; EPICS tech-talk
*Subject:* Re: Is anyone building AreaDetector with Sumo?



On 8/22/19 12:54 AM, Jeong Han Lee wrote:
Hi Andrew,


On 8/21/19 8:14 PM, Johnson, Andrew N. via Tech-talk wrote:
I realise there probably aren't many sites out there using the HZB
Sumo package <https://goetzpf.bitbucket.io/sumo/>, but has anyone
who does use it worked out how to configure and build AreaDetector
with it, either as a series of separate modules or as one big module?

Unlike most EPICS modules AreaDetector has multiple kinds of RELEASE
files that need to be populated, and a non-trivial configuration
process (which is well-documented
<https://areadetector.github.io/master/install_guide.html>).

The Sumo tool automates the configuration and building of sets of
EPICS modules on demand, but I'm not sure if it can cope with
configuring AreaDetector. If someone has succeeded in doing so I
would be grateful to hear details or ideas how best to approach it -
I haven't tried yet and I will need to do that soon.


      If the Sumo tool does its job well with the most EPICS modules, I
think, the tool does the same job on the AreaDetector also. But we may
not use the current global configuration files of areadetector with
the  Sumo tool, because here we (ESS) can build them as individual
modules,  and combine "necessary components" to build "an Application"
and run an  IOC without any issues.


      For example, in order to see images from a PointGrey  (FLIR)
camera,

      Here (ESS), we define system libraries and ADSupport clearly in
terms of OS. And we compile ADSupport as a module, And we compile
ADCore  which has the maximum configuration options with both
dependent  libraries (system and ADSupport) together. And we compile
ADPointGrey  according to ADCore, ADSupport, and system libraries.
(Note that the  vendor libraries also we have to consider.)

      The full dependent chain for my example (ignore system libraries
and  vendor lib) is

      EPICS Base < Asyn < ADsupport < ADCore < ADPointGrey < FLIR
Camera  IOC application

         This is not true, and the following is the correct one.

<pre>
    ```
         *  EPICS Base -> asyn -> ADCore <- ADSupport
                                  |
                                  V
            Vendor Lib -> ADPointGrey -> FLIR Camera IOC application
``` </pre>

       Best,
       Han


      In addition, you also have to consider how you would like to
handle  all template files and configuration files in the different manners.

      BTW, how Debian-based facilities does handle the areadetector?


      HTH,
      Han




- Andrew

--
Complexity comes for free, Simplicity you have to work for.



References:
Is anyone building AreaDetector with Sumo? Johnson, Andrew N. via Tech-talk
Re: Is anyone building AreaDetector with Sumo? Jeong Han Lee via Tech-talk
Re: Is anyone building AreaDetector with Sumo? Jeong Han Lee via Tech-talk
Re: Is anyone building AreaDetector with Sumo? Mark Rivers via Tech-talk
Re: Is anyone building AreaDetector with Sumo? Jeong Han Lee via Tech-talk
RE: Is anyone building AreaDetector with Sumo? Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: Is anyone building AreaDetector with Sumo? Ivashkevych, Oksana via Tech-talk
Next: Sumo test Jörn Dreyer via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Is anyone building AreaDetector with Sumo? Mark Rivers via Tech-talk
Next: RE: Is anyone building AreaDetector with Sumo? Ivashkevych, Oksana via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024