I appear to have discovered a bug in longoutRecord.c under R3.13.4 which
probably dates back to R3.13.3, when the drvh & drvl fields were added.
The manifestation is that a longout record with OMSL in closed_loop and
a constant value in the DOL link, will end up with an arbitrary value
in VAL when the record is processed.
The culpret is in the following code from the "process" routine:
if (!plongout->pact) {
if (plongout->omsl == CLOSED_LOOP) {
status = dbGetLink(&(plongout->dol),DBR_LONG,
&value,0,0);
if (plongout->dol.type!=CONSTANT && RTN_SUCCESS(status))
plongout->udf=FALSE;
}
else {
value = plongout->val;
}
if (!status) convert(plongout,value);
}
If dol.type is CONSTANT, dbGetLink does not fetch the link value, and so
the variable "value" is never initialized.
The fix, I've implemented for now is to initialize "value" in its declaration
at the begining of the process routine, i.e:
long value=plongout->val;
This restores the longout record to its previous behavior -- which is not
the same as, for example, an ao record with the similar setup since it
allows you to change the value by writing to the VAL field. For that, however,
we'd probably have to add another field to longout (such as the ao's PVAL
field).
Eric Bjorklund
LANSCE-6 Controls
Los Alamos Neutron Scattering Center.
[email protected]
- Replies:
- Re: longoutRecord Bug Andy Foster
- Navigate by Date:
- Prev:
Is anyone using the VMIC 4100 module ?? Kristi Luchini
- Next:
Problems with GSOctalRS232 Leng Yongbin
- 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:
Is anyone using the VMIC 4100 module ?? Kristi Luchini
- Next:
Re: longoutRecord Bug Andy Foster
- 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
|