Hi all,
I have a quite nasty problem with the mbboDirect record.
When I write a bit pattern directly into the VAL field instead of B0...BF, and
the record has UDF=1, the record writes out the old value instead of the new
one. According to the record reference manual, this is not an illegal operation.
Normally it works. Even if the UDF becomes true during run-time, the worst thing
that happens is that the new value is ignored (which is already bad enough). But
after a reboot the record writes out 0 (and thus switches off all connected
hardware).
The problem is here:
static long process(mbboDirectRecord *prec)
{
...
if (!prec->pact) {
...
if(prec->udf) {
recGblSetSevr(prec,UDF_ALARM,INVALID_ALARM);
goto CONTINUE;
}
...
/* convert val to rval */
convert(prec);
}
CONTINUE:
...
I am not sure what the purpose of this code is. The record never sets udf true.
Thus only the device support can do so. Thus it cannot make sense the test udf
BEFORE the device support is called.
Best regards,
Dirk
--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182
- Replies:
- Re: mbboDirect problem Andrew Johnson
- Navigate by Date:
- Prev:
Re: Remote I/O John William Sinclair
- Next:
Re: Remote I/O & RT linux David Dudley
- 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:
labCa 3.1 for Windows John Dobbins
- Next:
Re: mbboDirect problem 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
|