Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 18 Dec 2009 12:05:14 -0600

Hi Dirk,

On Friday 18 December 2009 08:38:35 Dirk Zimoch wrote:
>
> 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).

If UDF is true, the record severity should be INVALID, and what happens then 
is controlled by the setting of the IVOA and IVOV fields (thus I dispute your 
"bad enough" claim since you can control what should happen in this case).

I also don't think your analysis of the problem location is correct.  The 
dbPut() routine in dbAccess.c explicitly checks for a write to the VAL field 
and clears UDF in that case (which happens before the record gets processed), 
thus writing to the VAL field should never allow that prec->udf test to 
succeed.

What I think is happening in your case is that the VAL field is being 
overwritten by the code immediately below the prec->udf test, which converts 
the B0..B15 bits into VAL; this is happening because at startup NSEV is 
NO_ALARM, SEVR is INVALID and you probably have OMSL set to Supervisory.

Can you turn your design around and use DOL to fetch the new value rather than 
putting it directly into the VAL field?  That way OMSL will be closed_loop so 
the bit conversion code won't get executed.  Actually you could just set OMSL 
to closed_loop anyhow without setting DOL which should be enough to stop it.

I'm not saying the code shouldn't be changed if someone wants to come up with 
a patch to fix this though.

> 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.

UDF defaults to true at startup.  In normal operation the code ensures that we 
follow the IVOA/IVOV settings until such time as a real value is provided.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System