Re: few questions on autosave

[Jeong Han Lee via Tech-talk <tech-talk@aps.anl.gov>]

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 <tech-talk-bounces@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@gmail.com>; Mark Rivers 
> <rivers@cars.uchicago.edu>
> *Cc:* tech-talk <tech-talk@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@aps.anl.gov 
> <mailto:tech-talk-bounces@aps.anl.gov>> on behalf of Mark Rivers via 
> Tech-talk <tech-talk@aps.anl.gov <mailto:tech-talk@aps.anl.gov>>
> *Sent:* 15 October 2019 19:06
> *To:* 'Jeong Han Lee' <citadel.lee@gmail.com <mailto:citadel.lee@gmail.com>>
> *Cc:* tech-talk <tech-talk@aps.anl.gov <mailto:tech-talk@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@aps.anl.gov 
> <mailto:tech-talk-bounces@aps.anl.gov>> On Behalf Of Jeong Han Lee via 
> Tech-talk
> Sent: Thursday, October 10, 2019 5:49 AM
> To: tech-talk@aps.anl.gov <mailto:tech-talk@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