Re: Conversion issues (analog device support with float type raw data)

[Michael Davidsaver <mdavidsaver@bnl.gov>]

On 01/09/2015 05:04 AM, Ralph Lange wrote:
...
> This leads to the situation that for some input records (if they are
> connected to integer type raw data) the conversion can be tested by
> doing caputs to the RVAL field, for the other records caputs to the RVAL
> field are just being ignored.

Been there. done that.  Would like to stop doing so in future.

> Does anyone have a good idea how to straighten this out in a reasonable
> and compatible way?

I've considered a couple of approaches.

1. As you suggest, return 3; or similar.  Not great, but at least
contains the uglyness in two places (ai and ao)

2. library functions.  Not sure exactly what form this would take.
Something along the lines of what you (Ralph) did recently for NaN handling.

Somewhere I have some code from a half-day experiment in consolidating
the commonalities of ai and ao into an analogCommon recordtype (and thus
structure).  The ai/ao types would then include this instead of directly
including dbCommon.

Part of this was to consolidate the unit conversion code since ao and ai
need conversions in both directions (one in init_record and the reverse
in read/write).


> Admittedly this is not really cleaning things up a lot, but as long as
> there are no variable type fields in records, I don't see a way around
> adding a field for a double type raw value.

Personally, I could live without RVAL.