Re: Issues with PVXS

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Ralph,

• I would be really surprised if PXVS changed any user-configured data types. Please verify that the new AD plugin really calls PVXS with data structures that are different from what you see on the network.

I'm sure you are correct.  I believe the issue is that PVXS is promoting the datatype during an assignment in the plugin code.  This is not obvious.

This is the line that sets the codec.parameters field in ntndArrayConverterPvxs.cpp:

https://github.com/areaDetector/ADCore/blob/6e950ed29d4372bc0a88836a007446f33d8facd6/ADApp/ntndArrayConverterSrc/ntndArrayConverterPvxs.cpp#L361

    m_value["codec.parameters"] = (int32_t) NDDataTypeToScalar[src->dataType];

m_value is of type pvxs::Value.  It is doing its best to define codec.parameters as being of type int32_t.

However, as far as I can tell PXVS use the StoreType enum to define the datatypes that can be stored.

https://github.com/epics-base/pvxs/blob/48b260d008bd1d65c5f132c54523e27b41d0f4c3/src/pvxs/data.h#L30

It is:

enum struct StoreType : uint8_t {

    Null,     //!< no associate storage

    Bool,     //!< bool

    UInteger, //!< uint64_t

    Integer,  //!< int64_t

    Real,     //!< double

    String,   //!< std::string

    Compound, //!< Value

    Array,    //!< shared_array<const void>

};

Note that all numeric values are 64-bits.

This is where it maps all signed integers to 64-bits:

https://github.com/epics-base/pvxs/blob/48b260d008bd1d65c5f132c54523e27b41d0f4c3/src/pvxs/data.h#L59C1-L63C1

// map signed integers to int64_t

template<typename T>

struct StorageMap<T, typename std::enable_if<std::is_integral<T>::value && std::is_signed<T>::value>::type>

{ typedef int64_t store_t;  static constexpr StoreType code{StoreType::Integer}; };

So the issue is that PVXS is not allowing the creation of the same data structures that PVA does, at least not with the Value class.

There is a further issue.  NTNDArrays can be compressed.  For compressed arrays the datatype is effectively uint8_t, but the actual datatype of the original array must be conveyed.  By convention this is stored in codec.parameters as an int.  The int is one of the values in the ScalarType enum.

The ScalarType enum is defined here in PVA:

https://github.com/epics-base/pvDataCPP/blob/f66492ce4bad7e513cf048e3d5c697a127d2c6ba/src/pv/pvIntrospect.h#L221

For Java it is defined here:

https://github.com/epics-base/epicsCoreJava/blob/master/pvDataJava/src/org/epics/pvdata/pv/ScalarType.java

However, I cannot find an equivalent enum in PVXS.  So ntndArrayConverterPvxs.cpp currently has to include pv/pvIntrospect.h from PVA to get the required definition.  This is ugly since it is mixing code from PVA and PVXS.

Thanks,

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, January 19, 2026 2:30 AM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Issues with PVXS

 

Not good.

From a formal point of view...

If you look at the NT specification of the NTNDArray [1], the types of these parameters and attributes are not fixed in the specification, so both servers (the one using the original stack and the one using PVXS) are shipping different valid NTNDArrays.

To increase robustness, the general direction of fixing should be to make the receiving side cope with the allowed variability inside NTNDArray. The fastest and/or most practical approach might differ.

IOC crashes are unacceptable and bugs in any case, obviously.

I would be really surprised if PXVS changed any user-configured data types. Please verify that the new AD plugin really calls PVXS with data structures that are different from what you see on the network.

Cheers,
~Ralph

[1] https://docs.epics-controls.org/en/latest/pv-access/Normative-Types-Specification.html#ntndarray