Re: ai record doesn't do convert for floats?

["Pearson, Matthew R." <pearsonmr@ornl.gov>]

Hi,

Thanks folks, that explains it nicely. I was also a bit confused by the record reference manual stating that:

val = val * ESLO + EOFF

and now of course I know val is not VAL.

For the device I’m talking to, I’ve realized I can use asynInt32 anyway, which avoids me having two records.

Cheers,
Matt


> On Sep 18, 2015, at 5:30 PM, Andrew Johnson <anj@aps.anl.gov> wrote:
> 
> Hi Matt,
> 
> On 09/18/2015 03:48 PM, Pearson, Matthew R. wrote:
>> 
>> I’m wondering why it’s convention that the ai record doesn’t use its convert
>> function when using some types of device support routines. The analog value
>> read function should return status=2 according to the IOC developers guide,
>> and this causes it to not do any LINR type conversion on the VAL field.
> 
> The ai record reads raw data from the RVAL field which is a DBF_LONG,
> i.e. a 32-bit signed integer. If an ai device support gets its input as
> a floating-point value it is assumed that input processing such as
> engineering units conversion has already been done, thus the 'cooked'
> value it receives goes straight into the VAL field.
> 
> It is possible for device support to include code that implements some
> of the input processing such as smoothing (recent versions of the soft
> channel support do handle this), but making it do everything could
> adversely affect performance. Floating-point operations are expensive on
> some lower-end CPUs, thus the code was designed to avoid doing them
> unnecessarily. The linear or slope conversion process does 2
> FP-multiplies and 2 FP-adds, more if you use breakpoint tables and/or
> smoothing.
> 
>> I’m wondering why I can’t do this:
>> 
>> record(ai, "$(S):SE:CH1:PVRaw")
>> {
>>  field(DESC, "Process Variable CH1")
>>  field(DTYP, "asynFloat64")
>>  field(INP, "@asyn(n1,0,1)")
>>  field(SCAN, "I/O Intr")
>>  field(LINR, “SLOPE”)
>>  field(ESLO, “0.1”)
>> }
>> 
>> whatever the device support routine passes to the ai record is what I get in
>> VAL. So to do slope conversions I have to pass it to another ai record using
>> soft channel device support.
> 
> You wouldn't want your 64-bit floating-point input data to be truncated
> into a 32-bit integer after it has been read, so you don't want it to
> have to pass through the RVAL field.
> 
> It would be permissible for the asynFloat64 device support to look at
> the LINR field and do the additional processing you're asking for, but
> it doesn't at the moment and that would be a little unusual. If someone
> does add that code to Asyn, please examine the convert() routine in
> aiRecord.c for what users normally expect to happen.
> 
> - Andrew
> 
> -- 
> Light thinks it travels faster than anything but it is wrong.
> No matter how fast light travels, it finds the darkness has
> always got there first, and is waiting for it.
>    -- Terry Pratchett, Reaper Man
>