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: | mbboDirect vs. autosave |
From: | Eric Norum <[email protected]> |
To: | EPICS mailing list <[email protected]> |
Date: | Mon, 1 Dec 2014 15:17:03 -0800 |
A while back there were some threads discussing problems with mbboDirect record initialization. Those problems appear to extend to autosave/restore, too. I have an R3.14.12.3 IOC with an mbboDirect record of which I use four individual bits (4 through 7). I originally had record(mbboDirect, "$(P)$(R)EVR:event122trig") { field(DESC, "Heartbeat") field(DTYP, "asynUInt32Digital") field(OUT, "@asynMask($(PORT) 0x37A 0xFF 0)") field(NOBT, "8") field(MASK, "0xFF") info(autosaveFields_pass0, "VAL") } in the database, but that didn’t seem to work. Everything got set back to 0 on IOC startup even though the autosave life contains a non zero value (e.g. 128 or 192). It appears that info(autosaveFields_pass0, "B4 B5 B6 B7 VAL”) works, but feels like a bit of a hack to me. Is there any better way of handling this? Also, a client doing a caput to an mbboDirect record .VAL field doesn’t update the .Bx fields. I think that was discussed previously, though. Perhaps I should just replace the mbboDirect with a longout and make clients deal with all the bit testing/setting/clearing themselves. |