Re: Compression record returns double value for field "N" over channel access

[Timo Korhonen via Core-talk <core-talk at aps.anl.gov>]

Hi,

 

I chime in here as we discussed this with Georg yesterday. Using cainfo, the original IOC reports both native and request data types as double (DBF_DOUBLE resp. DBR_DOUBLE).

 

PVA (pvget and pvinfo) reports uint, by the way (not ulong).

 

Cheers,

 

Timo

 

From: Core-talk <core-talk-bounces at aps.anl.gov> on behalf of EPICS Core Talk <core-talk at aps.anl.gov>
Reply to: Ralph Lange <ralph.lange at gmx.de>
Date: Friday, 25 November 2022 at 11:26
To: EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: Compression record returns double value for field "N" over channel access

 

On Fri, 25 Nov 2022 at 11:14, Georg Weiss via Core-talk <core-talk at aps.anl.gov> wrote:

The field N (and NSAM) of a compression record should according to specification (https://epics.anl.gov/base/R7-0/6-docs/compressRecord.html) use ULONG. However, reading the field N over channel access apparently may return a double value:

 

>cainfo RFQ-010:RFS-EPR-110:Cur-ROI-Avg.N

RFQ-010:RFS-EPR-110:Cur-ROI-Avg.N

    State:            connected

    Host:             idmz-ro-epics-gw-tn.esss.lu.se:5064

    Access:           read, no write

    Native data type: DBF_DOUBLE

    Request type:     DBR_DOUBLE

    Element count:    1

 

The assumption is that since input data is an array of doubles, the field N uses same type.

While the above suggests query was handled by a ca gateway, I get the same result when not using a gateway.

 

Seems pvaccess returns a unsigned long type for field N.

 

Is this behavior expected?

 

Well, kind of.

 

Channel Access can't transport ULONG data. Instead, it will use DOUBLE.

 

Thus, when doing the cainfo against the original compress record (on the IOC), I would expect that you see the Native type as DBF_ULONG and the Request Type as DBR_DOUBLE.

 

The CA Gateway, however, has already a CA connection on the IOC side, so the data item for an original ULONG is of type DOUBLE inside the Gateway. This means when you're doing a cainfo against the Gateway, it would report both the Native and the Request type as DOUBLE.

 

Please re-check your statement that you see the same result against the original IOC. I would expect the Native type to be ULONG in that case.

 

Cheers,

~Ralph