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> 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 Hi all, For reference, these autosave tags in the database were added by SLAC in aravisGigE here: 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>
Hi 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. -- 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. |