At the moment, EXtra-data treats keys that have only RUN but no CONTROL values as separate. They are not listed as part of SourceData.keys() and cannot have a KeyData object associated with them. The only way to access them is via the dedicated SourceData.run_values() interface. On the Karabo side as far as I can see, a property primarily ends up not having a CONTROL section when its daqPolicy attribute is set to IGNORE or its type is not supported for train-resolved data (e.g. strings).
While I'm not aware of any critical properties affected by this, I did encounter a couple of very useful properties recently that only have RUN values beyond technical ones like deviceClass. The PulsePatternDecoder e.g. indicates the laser source it is set to watch for in such a way, there are spectrometer devices saving the background they substracted at runtime this way and finally string settings useful to interpret the operating mode a particular device had.
The biggest gripe I have with this situation is discoverability by not being included in SourceData.keys(), in particular combined with the fact they are somewhat mentioned in DataCollection.info(). After all, they haven been a property of the original device, they just happen to not be train-resolved. Including them in SourceData.keys() however implies that SourceData[<key>] should now throw a PropertyNameError and thus open a much larger issue of supporting such keys in some way in the KeyData interface. I don't think this is impossible however and could immediately think of two ways:
- Make
KeyData aware and throw exceptions (or return empty result?) in all train-based methods (e.g. .select_trains(), .ndarray()) while supporting others (.entry_shape, .as_single_value())
- Use different
RunData class to achieve the same effect
At the moment, EXtra-data treats keys that have only
RUNbut noCONTROLvalues as separate. They are not listed as part ofSourceData.keys()and cannot have aKeyDataobject associated with them. The only way to access them is via the dedicatedSourceData.run_values()interface. On the Karabo side as far as I can see, a property primarily ends up not having aCONTROLsection when itsdaqPolicyattribute is set toIGNOREor its type is not supported for train-resolved data (e.g. strings).While I'm not aware of any critical properties affected by this, I did encounter a couple of very useful properties recently that only have
RUNvalues beyond technical ones likedeviceClass. ThePulsePatternDecodere.g. indicates the laser source it is set to watch for in such a way, there are spectrometer devices saving the background they substracted at runtime this way and finally string settings useful to interpret the operating mode a particular device had.The biggest gripe I have with this situation is discoverability by not being included in
SourceData.keys(), in particular combined with the fact they are somewhat mentioned inDataCollection.info(). After all, they haven been a property of the original device, they just happen to not be train-resolved. Including them inSourceData.keys()however implies thatSourceData[<key>]should now throw aPropertyNameErrorand thus open a much larger issue of supporting such keys in some way in theKeyDatainterface. I don't think this is impossible however and could immediately think of two ways:KeyDataaware and throw exceptions (or return empty result?) in all train-based methods (e.g..select_trains(),.ndarray()) while supporting others (.entry_shape,.as_single_value())RunDataclass to achieve the same effect