Experimental Physics and
Industrial Control System

Jeong Han Lee via Tech-talk <[email protected]> · Thu, 17 Oct 2019 18:36:25 +0200

I appreciate your comments, Matt and Tom.

I've found the workaround with different info taga, and complex request

files within our unique environment at ESS. I am thinking I may think to

write a suggestion to all area detector integrators based on your

valuable comments and Mark's comments.

I hope it may resolve some potential issues in near future at ESS.

Thanks,
Han

On 10/17/19 5:48 PM, Pearson, Matthew R. wrote:

Hi,

We take a couple of different approaches for areaDetector based IOCs:

On some IOCs I don’t autogenerate the req files using the info fields,

and I use a manually created list instead for the few PVs that the users

expect to be autosaved (eg. a camera gain, or the position of a ROI on a

user screen, or an exposure time). To ensure the rest of the system is

restored to a working state on a reboot I either do a few dbpfs in the

startup script, or do the same via some database logic. Sometimes the

database logic would be switching between multiple system

configurations, and it just resets the last configuration that the user

selected.

On others I do autogenerate the req files using the info fields, and

then I rely on autosave to configure the system on a reboot. That’s for

systems that are fairly complex and configured in different ways on

different beamlines and it would be too much of a burden to manually

maintain a list of req files for each beamline. For these systems I do

have a way to verify configuration using a script (checking the current

configuration against previous known good states).

Cheers,

Matt

*From:* Tech-talk <[email protected]> *On Behalf Of *Cobb,

Tom (DLSLtd,RAL,LSCI) via Tech-talk

*Sent:* Thursday, October 17, 2019 4:31 AM

*To:* 'Jeong Han Lee' <[email protected]>; Mark Rivers

<[email protected]>

*Cc:* tech-talk <[email protected]>
*Subject:* [EXTERNAL] Re: few questions on autosave

Hi all,

For reference, these autosave tags in the database were added by SLAC in

aravisGigE here:

https://github.com/areaDetector/aravisGigE/commit/0eac2d00d4f46c6d5a083928c0a1325ad33f341a

I'm not sure why they chose to autosave so many fields.

At Diamond we typically do not use autosave at all for GigE cameras.

This is because our users expect restarting an IOC to take the system

back to a known good state, so we use the database PINI'd values or dbpf

calls to make sure this happens. Any changes from these "known good"

settings are captured in the configure phase of scans.

I would be happy to see a much reduced list of "default" autosaved

fields, in line with what the other areaDetector drivers do.

Thanks,

Tom

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

*From:*Tech-talk <[email protected]

<mailto:[email protected]>> on behalf of Mark Rivers via

Tech-talk <[email protected] <mailto:[email protected]>>

*Sent:* 15 October 2019 19:06
*To:* 'Jeong Han Lee' <[email protected] <mailto:[email protected]>>
*Cc:* tech-talk <[email protected] <mailto:[email protected]>>
*Subject:* RE: few questions on autosave

Hi Han,

 >   I would like to raise few simple questions related with autosave.

 > These questions are related with predefined req files and the info

tag in db  or template files.

 >   Since `autosaveBuild` is supported from base 3.15.0.2, or a patch

to EPICS base 3.14, are there any specific reasons why areaDetector

keeps using only req files instead of info tags in template files?

I think you are confusing two different features of autosave:

autosaveBuild and makeAutosaveFiles.

autosaveBuild does not parse db or template files for info tags to

define fields to be autosaved.  What autosaveBuild does is it to

automatically search for a corresponding .req file for each db or

template file that is loaded.  If it finds a corresponding .req file it

adds that .req file to built_settings.req.  Thus the purpose of this

utility is to save the developer from having to manually create a

complete auto_settings.sav file for each IOC, based on the databases it

loads.  autosaveBuild does require base 3.15.0.2 or a patch to EPICS

base 3.14.

makeAutosaveFiles is the command that reads the entire databases loaded

into the IOC and searches for info nodes named autosaveFields or

autosaveFields_pass0.  It constructs a list of PV names to be saved and

writes them to the info_settings.req and info_positions.req files.  I

think this is the command you are actually talking about.  Note that it

is supported in 3.14 and does not require any patches.

My personal feeling is that using info nodes to autogenerate .req files

may not be the best approach.  The reason is that the choice of what

records and fields to add to autosave can be a site-specific decision.

For example, should the .PREC field of every record be in autosave or

not?  Some sites may want this, but some may not because they want those

fields to revert to a "known state" when the IOC restarts, even if some

user changed the PREC field for a specific experiment.  I feel that

customizing the .req file is much simpler and less error prone than

customizing the .template file.  For example in ADProsilica

prosilica.template is 960 lines long (and currently does not contain any

info nodes), while prosilica_settings.req is only 23 lines long.  Sites

can easily create a new version of prosilica_settings.req and put it in

a location earlier in the autosave requestfile_path to use the new

version.  This is much easier to maintain than editing the

prosilca.template file itself to change the info nodes.

 > In addition, ADSpinnaker module, it uses req files and info tag

together. Do you have any specific reasons why both configurations are

in that one module?

Actually spinnaker.template in the current version of ADSpinnaker does

not contain any info nodes.

What does contain info nodes are the .template files in ADGenICam that

are auto-generated using the camera XML file and a Python script.  Those

are there because that Python script was derived from the one in

aravisGigE that put them in and I have not removed them.  However, I

really question how useful they are.  Consider the file

PGR_BlackflyS_50S5C.template for a FLIR/Point Grey camera.  It contains

619 lines like this:

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU TSE")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU

TSE PINI VAL")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU TSE")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU

TSE PINI VAL")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU TSE")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU

TSE PINI VAL")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU TSE")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU

TSE PINI VAL")

   info(autosaveFields, "DESC ZRSV ONSV TWSV THSV FRSV FVSV SXSV SVSV

EISV NISV TESV ELSV TVSV TTSV FTSV FFSV TSE")

   info(autosaveFields, "DESC ZRSV ONSV TWSV THSV FRSV FVSV SXSV SVSV

EISV NISV TESV ELSV TVSV TTSV FTSV FFSV TSE PINI VAL")

   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU TSE")
   info(autosaveFields, "DESC LOLO LOW HIGH HIHI LLSV LSV HSV HHSV EGU TSE")

Altogether it defines over 8000 PVs to be autosaved, including such very

important PVs as PINI, DESC, etc.  Do you really want a user to be able

to modify those fields and have those changes survive an IOC restart?

Mark

-----Original Message-----

From: Tech-talk <[email protected]

<mailto:[email protected]>> On Behalf Of Jeong Han Lee via

Tech-talk

Sent: Thursday, October 10, 2019 5:49 AM
To: [email protected] <mailto:[email protected]>
Subject: few questions on autosave

Hi All, and especially areaDetector Developers,

    I would like to raise few simple questions related with autosave.

These questions are related with predefined req files and the info tag

in db  or template files.

    Since `autosaveBuild` is supported from base 3.15.0.2, or a patch to

EPICS base 3.14, are there any specific reasons why areaDetector keeps

using only req files instead of info tags in template files?

    In addition, ADSpinnaker module, it uses req files and info tag

together. Do you have any specific reasons why both configurations are

in that one module?

    Best,
    Han

--

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