I will fix this in the next release of both 3.13 and 3.14. Andy was the first
one to make we aware of this bug.
Marty Kraimer
Andy Foster wrote:
>
> Hi Eric,
>
> Yes, I noticed this too and have "spoken" (over E-mail) with
> Marty about it.
>
> There are other records which exhibit the same feature, namely:
> dfanout, stringout, steppermotor.
>
> All have code similar to the longout with respect to the DOL
> link. What I did was changed the longout and others to be like
> this:
>
> if (!plongout->pact) {
> if( (plongout->dol.type != CONSTANT) && (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);
> }
>
> Then for a CONSTANT DOL type, the value gets initialized as it does
> in an ao record.
>
> Cheers,
>
> Andy
>
> Eric Bjorklund wrote:
> >
> > 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]
>
> --
> Observatory Sciences Limited Email: [email protected]
> William James House Tel: 44 - (0)1223 - 508257
> Cowley Road Fax: 44 - (0)1223 - 508258
> Cambridge, CB4 0WX, UK http://www.observatorysciences.co.uk
- References:
- longoutRecord Bug Eric Bjorklund
- Re: longoutRecord Bug Andy Foster
- Navigate by Date:
- Prev:
Re: longoutRecord Bug Andy Foster
- Next:
Re: Problems with GSOctalRS232 Andrew Johnson
- 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: longoutRecord Bug Andy Foster
- 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
|