Open simon-ess opened 4 months ago
The absence of a difference is baked a long way into the IOC code, deliberately so I believe (Bob D. might be able to explain that).
This isn't the only case where EPICS requires a client to know something about the PV it's connecting to. That also happens with an array of CHARs, is it a string or a series of 8-bit integers? The client has to know which it's meant to be to properly display the value.
While I was digging around I could see that CA probably fundamentally cannot distinguish between these two types, but I do think it should be possible to do so for PVA; given that we send the data types over the wire, we should be able to say that "this is an array, but its length is 1".
It's worth noting that one of the places that this decision is made at the moment is here; it's a very simply check that only looks at the length of the data and not the type of the data. This could be improved.
(This gives me flashbacks of coding in APL; it is actually a bit non-trivial to have arrays of length 1, although it is possible)
We can close this issue if this is truly how things should behave. But I think it is worth considering an improvement here.
The absence of a difference is baked a long way into the IOC code ...
Concretely, this difference is expressed to QSRV through struct dbChannel
having an element type and maximum number of elements, but no minimum element count. So testing that maximum is, I think, the best which can be done generically with the present dbAccess API. (without hard coding knowledge about certain fields of certain record types)
Of course, this still leaves cases where a "scalar" actually turns out to have zero elements. At which point things get messy...
... we should be able to say that "this is an array, but its length is 1".
I have had requests to allow modifications of field type mapping between PDB and PVA in places where there is no clear one-to-one relation. eg. coerce numeric to boolean
. One ~obvious, though open ended, way to express this would be through info()
tags.
Describe the bug It is not possible at the moment to distinguish between the following records via PVAccess:
This ultimately manifests in the fact that fetching and processing data from a record that is a waveform of strings typically requires some additional checks, since you get something like
whereas if the array has
NELM > 1
then you instead getwhich is typically handled differently in e.g. pyepics, p4p, etc.
Note that this is not really restricted to PVXS, or even PVAccessCPP, but also ChannelAccess. In channel access I believe that due to the protocol there is no possible fix; in PVAccess, it should be fixable since an array of length 1 of type string is sent as an NTScalar, whereas an array of length > 1 is sent as an NTScalarArray; it should be possible to send an array of length one also as an NTScalarArray, which should fix this.
To Reproduce Steps to reproduce the behavior:
Expected behavior This is a bit murky, because I might be proposing a breaking change in how IOCs communicate over PVAccess. I think it would be more consistent to have arrays always send as NTScalarArrays instead of NTScalars if they are length 1. But there might be a good reason for the current behaviour.
Information (please complete the following):
Additional context Add any other context about the problem here.