EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  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  Index 1994  1995  1996  <19971998  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 
<== Date ==> <== Thread ==>

Subject: Re: copying of monitored data
From: Marty Kraimer <[email protected]>
To: [email protected]
Date: Tue, 10 Jun 1997 14:03:19 -0500
Jeff Hill wrote:

> It does appear to work that way here also. This _is_ surprising
> behavior when you are attached to the .VAl field of a bo.
> After closer inspection I discovered that the get_enum_str() entry point
> in the bo record is not using the field pointed to by paddr. Instead it
> always uses the val field. I would classify this behavior as a bug for the
> following reasons:
> 
> 1) If another field in the bo record is of type dbr_enum and a client
> fetches it as a string then it will receive the value of the wrong field.
> Even if there isn't another field of type dbr_enum, we know that
> new records are created by copying records in base and we dont
> want to encourage this practice.
> 
> 2) The dbr_enum values stored in the CA monitor value queue
> are not used (because pfield is pointing at the monitor queue and
> not at the database)

I will agree that the code is better written if get_enum_str checks
the field specified by the DBADDR argument. The correct way in 3.13 is
to use code like the following:
  index = dbGetFieldIndex(paddr);
  if(index==biRecordVAL) ...

  or use a switch statement on index.

In fact this applys to ALL record support modules that have a DBADDR
argument.

HOWEVER,

The biRecord.c support code is not incorrect because there get_enum_str,
put_enum_str, get_enum_strs will ONLY get called if the field type
in question is DBF_ENUM. The only such field in the biRecord is VAL.
Many record support modules in base make this assumption.

Marty Kraimer

References:
Re: copying of monitored data Jeff Hill

Navigate by Date:
Prev: ACS Microstepper Drives Guy_Jennings
Next: Re: copying of monitored data Marty Kraimer
Index: 1994  1995  1996  <19971998  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: copying of monitored data Jeff Hill
Next: Re: copying of monitored data Marty Kraimer
Index: 1994  1995  1996  <19971998  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, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·