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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: mbboDirect problems |
From: | Mark Rivers <[email protected]> |
To: | "'Eric Norum'" <[email protected]> |
Cc: | EPICS mailing list <[email protected]> |
Date: | Mon, 8 Sep 2014 22:01:44 +0000 |
I think that is the way the mbboRecord works. This is from the process() function: if(prec->nsev < INVALID_ALARM && prec->sevr == INVALID_ALARM && prec->omsl == menuOmslsupervisory) { /* reload value field with B0 - B15 */ int offset = 1, i; unsigned char *bit = &(prec->b0); for (i=0; i<NUM_BITS; i++, offset = offset << 1, bit++) { if (*bit) prec->val |= offset; else prec->val &= ~offset; } } /* convert val to rval */ convert(prec); If I read this correctly then the first time the record processes sevr==INVALID_ALARM so it will overwrite the VAL field with the Bn fields. Mark From: Eric Norum [mailto:[email protected]]
Yes. On Sep 8, 2014, at 2:41 PM, Mark Rivers <[email protected]> wrote:
Does it work if you write to a bit field? From: Eric
Norum [mailto:[email protected]] The VAL field. On Sep 8, 2014, at 2:11 PM, Mark Rivers <[email protected]> wrote:
What field is the client writing to? The VAL field or an individual bit? In R4-21 the following change was made: “Improved the initMbboDirect function in devAsynUInt32Digital.c. If an initial value is read successfully from the driver it now sets the .Bn fields in the record. It also sets VAL rather than RVAL and returns 2 rather than 0. Thanks to Andrew Johnson for
this.” Mark From: Eric
Norum [mailto:[email protected]] I have a number of mbboDirect records like: record(mbboDirect, "$(P)$(R)EVR:event12trig") { field(DESC, "Extraction pre-trigger") field(DTYP, "asynUInt32Digital") field(OUT, "@asynMask($(PORT) 0x30C 0xFF 0)") field(NOBT, "8") field(MASK, "0xFF") }
The IOC starts up and reads back the initial value of this record properly. The *first* caput to the record (I’ve tried from EDM and from caput) writes the readback value again, not the value from the client. Subsequent caputs do write the value from the client. It’s only the first operation that uses old data.
Is this a known problem? -- -- -- |