Hi Márcio,
Thanks for this. I see it too, but I don't understand what's causing it. The aao record also behaves in the same way, but the aSub record does not.
Details:
Using base 3.15.5
When a waveform or aao record's NELM field is set to 1, autosave saves the value of the .VAL field as a scalar, and fails to restore it at boot time. If an aSub record has a field with 1 element, that field value is saved as
a scalar and the value is restored correctly at boot time. (All fields restore correctly using run-time restore (fdbrestoreX()), but that's expected,
because it's just channel access.)
When I use base 3.14.12.5, all of these fields are restored correctly at boot time. I tried copying the waveform record from 3.14.12.5 to 3.15.5 and rebuilding, but that doesn't change the behavior of 3.15.5, which suggests to me that the difference is in
dbStaticLib.
I think the line in dbrestore.c that isn't doing the same thing under 3.15.5 that it did under 3.14.12.5 is this:
status = (*dbFastPutConvertRoutine[DBR_STRING][field_type])
where field_type has the value DBF_NOACCESS. But I don't understand how the aSubRecord's .A field behaves differently than the waveform record's .VAL field, because they are both one element array fields.
For concreteness, here's my database file:
record(waveform, "$(P)s0") {
field(NELM, "1")
field(FTVL,"LONG")
}
record(waveform, "$(P)s1") {
field(NELM, "1")
field(FTVL,"DOUBLE")
}
record(aao, "$(P)aao") {
field(NELM, "1")
field(FTVL,"LONG")
}
record(aSub, "$(P)aSub") {
field(SNAM, "piezoDiffract")
field(FTA, "LONG")
field(NOA, "1")
}
Here's my auto_settings.req file:
tmm:s0.VAL
tmm:s1.VAL
tmm:aao
tmm:aSub.A
Tim Mooney (
[email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
Hello,
here at SLAC, we saw that autosave is failing to recover the data for a waveform with 1 element. For testing purposes, we changed manually NELM to 2 and the recovery succeeded. Another test was to manually edit the sav file, adding the keyword @array@ and
the recovering succeeded, too.
I saw the following comment in 5.4.1 release: "Previously, restoring an array which had been saved with zero or one values failed. Also, manual restore (including restore by configMenu)
of any array PV caused a seg fault.".
As we are using 5.7.1, I think this problem is already corrected since 5.4.1. The behavior was observed when using EPICS 3.15.
The strange thing is that the same version of autosave seems to be working in EPICS 3.14, but not in 3.15.
I saw that autosave uses ca_element_count() from the channel access API. Maybe something changed in this function in EPICS 3.15?
Thank you for your help.
Márcio Paduan Donadio
System Control Engineer - SLAC