Experimental Physics and Industrial Control System
|
Our users also found the 8-file limitation too severe. I increased it to 20
quite easily.
Some of our users also like to use the autorestore function to initialise
database entries, without any corresponding autosave function. They
generate the autosave files using other software. This practice has
established itself to the extent that their autosave files are even located
on a read-only file system ... which then resulted in moans about the error
messages generated by autorestore when it couldn't write its backup files.
This led to a less trivial modification to allow files to be flagged as
"restore-only", in which case there is no attempt to write backup files
during the autorestore phase.
Regarding the question of which pass fields should be restored in, the only
special case I have come across is that of motor VAL fields. As I
understand it, if the motor record sees that a VME58 card has a non-zero
step counter, it will use this value to initialise the motor's VAL field.
The assumption is that a warm reboot of the IOC has just occurred, and that
the step counter is therefore valid. This seems to me to be a good
strategy. However, for motors without encoders, it is standard practice to
autosaverestore the VAL field so that a motor's position will generally
survive a power cycle of the IOC. In that case, the autorestore should be
PASS 0 ONLY. A non-zero step counter in the VME58 card will then take
precedence over autorestore.
David
Tim Mooney wrote:
The 8-file limitation is still in the code. I never thought about having a
restore file per device. The limitation would be easy to lift if you
didn't
care about status PV's. There's a hard-coded structure in dbrestore.c, and
a macro in save_restore.h. I think that's all you'd have to change, but
I've
never tried it.
Pass 1 is just after record initialization. Too late to restore link
fields, and too late to use the restored value in device support's init,
but ok for most other things, including arrays and fields whose type is
set during record init.
It's probably best to use both passes unless you want to avoid overwriting
a value the record/device set during its init. Otherwise you have to
segregate PV's by field types, because some types can only be restored in
one of the two passes.
Tim
Mark Rivers wrote:
I don't know about the 8 file limitation. Tim Mooney may know about
that.
pass0 is like setting VAL in the db file. pass1 is not like a caput,
it does
not cause the record to process, because it is all still done before
iocInit.
It has to do with the timing relative to when links have been
established I
think.
vxWorks typically has no local disk, and NFS is the preferred file
system.
For computer-based IOC you don't need to worry about, you can just
save to a
local disk.
Mark
________________________________
From: Emmanuel Mayssat [mailto:[email protected]] Sent:
Wed
4/16/2008 7:11 PM To: Mark Rivers Cc: epics Subject: RE: autosave issues
Mark,
I implemented autosave relatively easily thanks to the documentation.
For the
set_passX_restoreFile functions, it says that only 8 files can be
restored at
each pass.
This is rather an important limitation if I have a restore file per
device
(and not 1 per ioc). Is this limitation still applicable?
Is doing a restore at pass0 equivalent to setting the VAL fields in
the db
file? For pass1, is it equivalent to having several caputs on a
running ioc?
Why do they recommend saving vxWorks station over NFS? I assume it is
only
because of a storage space limitation. If that is the case, then it is
not
applicable for computer-based IOC. Isn't it?
Regards,
-- E
On Tue, 2008-04-15 at 21:22 -0500, Mark Rivers wrote:
The problems are probably less frequent than that. And a beamline
might be
4 IOCs.
The issues tend to arise during power or network failures when the
vxWorks
VME IOC is in the middle of saving the file via NFS.
There are safeguards now in place that make this much less likely. And
there are backup files created by the autosave system that can be
recovered
from.
Mark
________________________________
From: [email protected] on behalf of Emmanuel Mayssat
Sent: Tue
4/15/2008 8:35 PM To: epics Subject: autosave issues
Hello again,
I was looking at autosave record/functions. I read that APS is
experiencing
at least 1 autosave issue per beamline, per year. Can anyone expend on
that?
I assume that files are being corrupted or such... How could that
happen?
-- Emmanuel
- References:
- autosave issues Emmanuel Mayssat
- RE: autosave issues Mark Rivers
- RE: autosave issues Emmanuel Mayssat
- RE: autosave issues Mark Rivers
- Re: autosave issues Tim Mooney
- Navigate by Date:
- Prev:
Re: autosave issues Tim Mooney
- Next:
RE: sequence compilation in multi-device IOC Emmanuel Mayssat
- 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: autosave issues Tim Mooney
- Next:
Channel Archiver building problem in Make Install command Tasaddaq Ali Khan
- 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, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|