Experimental Physics and
Industrial Control System

Hi Andrew,
The record already protects itself from caput or dbpf with values > 1, so a DOL link
may be the only way to set VAL to be other than 0 or 1.

If no-one has replied to you that they need this behavior,
I'd like to propose it get fixed in the next release.

The fix is simple, and works at my site.

--- boRecord.c  (revision 3756)
+++ boRecord.c  (working copy)
@@ -202,7 +202,7 @@
                        status=dbGetLink(&pbo->dol,DBR_USHORT, &val,0,0);
                        pbo->pact = FALSE;
                        if(status==0){
-                               pbo->val = val;
+                               pbo->val = val == 0 ? 0 : 1;
                                pbo->udf = FALSE;
                        }else {
                                        recGblSetSevr(pbo,LINK_ALARM,INVALID_ALARM);


Best regards,
- Bruce

On 1/25/2011 4:13 PM, Andrew Johnson wrote:

Hi Bruce,

On Monday 24 January 2011 23:14:02 Bruce Hill wrote:

In all the bo record documentation I can find, record processing specifies:

if DOL is DB_LINK and OMSL is CLOSED_LOOP

     * get value from DOL
     * check for link alarm
     * force VAL to be 0 or 1

However, the boRecord.c source code for 3.14.9 and 3.14.11 does not do
this. If you read a non-zero value from the DOL link, VAL and RVAL
retain that non-zero value, even if it isn't a 1.

Does anyone know if this is intentional, or a bug?

I think this is a bug, but I'm not certain whether it's in the code or the
documentation.  I just checked the history all the way back to the beginning
of time (well, to when Marty first added the boRecord code to CVS in 1995) and
the VAL field has never been forced to be 0 or 1 during record processing.
Interestingly the forcing does happen at record initialization when DOL is a
constant.

If VAL is neither 0 nor 1 then ca_get as a string returns "Illegal_Value" and
RVAL is set to VAL; the behavior of RVAL is correct if the device support has
set MASK, RVAL is MASK for all non-zero VALs else zero.

Should we fix this in the 3.15 series?  Does anybody know of any databases
that rely on this weird behavior?

- Andrew

References:

bo Record not forcing VAL to 0 or 1 Bruce Hill

Re: bo Record not forcing VAL to 0 or 1 Andrew Johnson

Navigate by Date:

Prev: Re: GigE driver for Area Detector Eric Norum

Next: Re: Py-Epics and string waveform records Matt Newville

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: bo Record not forcing VAL to 0 or 1 Andrew Johnson

Next: CSS BOY Meter widget limits Paweł Prędki

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