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 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 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024
<== Date ==>		<== Thread ==>

Subject:	RE: few questions on autosave
From:	"Pearson, Matthew via Tech-talk" <tech-talk at aps.anl.gov>
To:	"Cobb, Tom (DLSLtd,RAL,LSCI)" <tom.cobb at diamond.ac.uk>, 'Jeong Han Lee' <citadel.lee at gmail.com>, Mark Rivers <rivers at cars.uchicago.edu>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Tue, 25 Jul 2023 21:19:43 +0000

Hi Tom,

I think there’s a lot of value in the current approach of using autosave tags in database templates. It ensures that, by default, you get consistent autosave behavior across different installs at the same facility, and even between facilities. To avoid the kind of issue Mark described, the developers can take a reasonable guess at what most users expects to be saved and if it works for ~90% of cases then that’s good enough. I think it’s obvious to most people that saving every field of every record is not the best approach.

For the remaining ~10% of cases, then perhaps manually defining the autosave req files is appropriate. I’ve had to do that a few times on a few systems. I have done it on a per-IOC basis, and version controlled the .req file with the IOC source files.

Another method is overriding the default behavior by loading additional database files that redefine the autosave tags for the affected records. Occasionally I have added a ‘special’ database template file to a support module to cater to a particular autosave edge case.

It’s usually a case of saving fewer PVs (and, perhaps, only a few PVs) than what would be saved if using the automatically generated req files. For example, we have a few motion control IOCs (controlling a single motor) that had to be completely defined by what’s in the database file, so a reboot guarantees a known good state, but we still had to autosave the DVAL position to deal with restoring the position after a controller reboot. So the request file was simply a single PV (restored before IOC init).

In the cases where we found we had to autosave additional PVs, we simply add an additional autosave tag to the database template file so that everybody eventually gets the same behavior. This is usually ok, but I take the view that it should be reviewed like any other change to a module source code or database logic.

Ideally, I would like to make a smooth process where a user identifies a PV that needs to be autosaved, and then it gets added to the req file and autosave refreshed so it starts saving that PV without restarting the IOC. Has anyone done this?

I haven’t, but it sounds cool!

Maybe a right-click context menu in a client with an option to “Autosave this PV”. It sends a message to a service, which then figures out the correct IOC, rewrites the request file, connects to the IOC and reloads the file, etc. But I can think of some complexities/risks involved. I think I’d rather get an e-mail asking me to autosave a particular PV.

Cheers,

Matt

Thanks,

Tom

From: Pearson, Matthew R. <pearsonmr at ornl.gov>
Sent: 17 October 2019 16:48
To: Cobb, Tom (DLSLtd,RAL,LSCI) <tom.cobb at diamond.ac.uk>; 'Jeong Han Lee' <citadel.lee at gmail.com>; Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: RE: few questions on autosave

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 <tech-talk-bounces at aps.anl.gov> On Behalf Of Cobb, Tom (DLSLtd,RAL,LSCI) via Tech-talk
Sent: Thursday, October 17, 2019 4:31 AM
To: 'Jeong Han Lee' <citadel.lee at gmail.com>; Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk <tech-talk at aps.anl.gov>
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 <tech-talk-bounces at aps.anl.gov> on behalf of Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
Sent: 15 October 2019 19:06
To: 'Jeong Han Lee' <citadel.lee at gmail.com>
Cc: tech-talk <tech-talk at aps.anl.gov>
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 <tech-talk-bounces at aps.anl.gov> On Behalf Of Jeong Han Lee via Tech-talk
Sent: Thursday, October 10, 2019 5:49 AM
To: tech-talk at aps.anl.gov
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

References:: Re: few questions on autosave Cobb, Tom (DLSLtd,RAL,LSCI) via Tech-talk

Navigate by Date:: Prev: Re: few questions on autosave Cobb, Tom (DLSLtd,RAL,LSCI) via Tech-talk; Next: Re: few questions on autosave Michael Davidsaver 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 2019 2020 2021 2022 <2023> 2024
Navigate by Thread:: Prev: Re: few questions on autosave Cobb, Tom (DLSLtd,RAL,LSCI) via Tech-talk; Next: Re: few questions on autosave Michael Davidsaver 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 2019 2020 2021 2022 <2023> 2024

ANJ, 25 Jul 2023

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System