Hi Kristi,
A agree that it's best for the database developer to write the request file and package it with the database file.
But I like your idea of using the info nodes in a database to generate an initial request file. I think I'd not pull PVs out of the file autosave generates from info nodes, or at least I'd not do it that way if I had more than just a few request files to write.
I'd probably write a python script, or get a student to write one.
Tim Mooney (mooney at anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
From: Luchini, Kristi L. <luchini at slac.stanford.edu>
Sent: Thursday, January 28, 2021 8:22 PM
To: Mooney, Tim M. <mooney at anl.gov>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: RE: autosave -- NOWRITE pvs request
Hi Tim,
Thanks for such a quick response.
>For each database, we have an autosave-request file, and this will be used if no user-written request file is found.
So it seems like the only solution is to generate my ow list of pvs by using the autogenerated file as my base. I’d perfer that the epics module/driver provide a “req” file,
which could be installed by the application and edited, where the “req” file had the name of the database as you described. However, I’ve already made this request but it looksl I’ll need to do this for now in my application.
>I did not answer your question about a NOWRITE option because I'm not sure I understand exactly what you mean, and I haven't thought of a good place to put such an option.
Not important.. This is feature we had with ChannelWatcher, where the “req” file provides 2 columns the left column the pvs to save and the right column an optional switch,
one of which was “/NOWRITE”. In the “sav” file monitored all the pvs but in the st.cmd file the restore load file only loaded those pvs from the “sav” file that did not have the “/NOWRITE” option in the “req” file. It’s useful during the run to what pvs
change in the “sav” file even if they won’t be restored, rather than traversing through displays you can do searches in the “sav” file using wildcards. It’s not going to save me time though here.. I’ll just generate my own autosave files thanks very much
for your help!!!
Best Regards,
-
Kristi
From: Mooney, Tim M. <mooney at anl.gov>
Sent: Thursday, January 28, 2021 5:24 PM
To: tech-talk at aps.anl.gov; Luchini, Kristi L. <luchini at slac.stanford.edu>
Subject: Re: autosave -- NOWRITE pvs request
This is one reason that we use autosaveBuild, instead of info fields, to allow a database developer to specify a default set of PVs for each instance of that database. In some
cases, it's essential for a database developer to be able to specify autosaved PVs, because the database depends on those PVs to restore its internal state. In other cases a new version of a database needs a new version of the request file, and it's helpful
for those files to be released together in a module version. But sometimes an end user needs to override those choices, and autosaveBuild supports this with a directory list.
For each database, we have an autosave-request file, and this will be used if no user-written request file is found. But request files are searched for in the order that directories
that might contain request files were specified. We often specify the IOC boot directory as one place request files might be found, and list it first so a file there will override the database developers default request file.
For example, these two commands:
set_requestfile_path(startup, "")
set_requestfile_path(area_detector, "ADApp/Db")
tell autosave to look in the IOC directory before looking in the areaDetector directory for request files, and this allows you to copy the request file from areaDetector, edit
it to meet your needs, and place it in the IOC directory.
I did not answer your question about a NOWRITE option because I'm not sure I understand exactly what you mean, and I haven't thought of a good place to put such an option.
Hi,
I’m having the following issue using autosave, where my ioc application includes a number of epics modules/driver, which use the info field on many pvs. This means that the ioc application does not have control over what is being
saved, unless I override the pvs in my application. Now in my application, I could save local pvs in a manually generated req file, and initially auto-generate the standard autosave files, edit those files and give them unique filenames and load these manually,
not using the auto-generate feature. However, numerous application are going to use these modules/driver and will have the same issues and will need to duplicate this work. So I’d like some way to turn off the save feature for some pvs in the “req” list.
For example:
If a “NOWRITE” option that could be set per pvs is available, then I could turn off the “info” field for select pv fields, so that the “req” file auto-generated would not include these pvs or would include them but comment them
out, so that the monitor would skip those pvs.
Is this feature or is there another method that other have used to solve this same problem?
Thanks,
-
Kristi Luchini
|