Experimental Physics and
Industrial Control System

"White, Greg via Tech-talk" <tech-talk at aps.anl.gov> · Mon, 18 Oct 2021 02:32:29 +0000

Hi Tom, good idea, especially on your second suggestion. May I help? 

In particular I’m interested in formalizing the second of your suggestions - especially units of columns. 

One could include a display_t[]. display_t includes units [1.1]. So the EBNF would be:

NTTable := 

structure
    string[]   labels              // Very short text describing each field below, i.e. column labels
    structure  value
        {scalar_t[]  colname}0+ // 0 or more scalar array instances, the column values.
    string     descriptor  : opt
    alarm_t    alarm       : opt
    time_t     timeStamp   : opt
    display_t[] display    : opt  *** array length as number of columns in value

Using display_t[] adds a bit of work for compliant implementations, but a lot of power given the relevance that data services are going to play over the next years. Users of course don’t need to add it, since it’s optional.

I wondered in the first version of the spec whether to include defined support for units per column of the NTTable. I left units out recognizing that through the optionality rule - an individual deployment is free to add a field for that deployment. For instance, a deployment could add a simple NTScalarArray for “units” of all the columns. That works since implementations of Normative Types are required to ignore fields they don’t recognize, so interop would be preserved although obviously there would be no normative interpretation. I made that choice to keep it simple, to help create the first set of compliant implementations and foster adoption. Now though, normative types are adopted and powerful, and the emerging need for science data services I think implies normative metadata.

On the PandA support field, I do think that should not be normative. That is, it should not be included explicitly as an optional field in the definition of NTTable, since then implementors are required to support it in order to claim compliance with the spec. That seems too selfish to me. I’d suggest using the optionality rule.

I’d be happy to add it to the spec doc. 

Re updating the spec, it looks like there are some issues with the NT Spec doc version in github.com/epics-base/ [1], which is now linked from epics-controls.org [2]. Importantly for our modification, the type magic number table of the original doc [3] is just a lot of text in [1]. So you don’t see the importance of the type version to forming the magic number that preserves interop between type versions. Would need to fix that. Also the versioning of the spec itself has been lost in the move to github. Not good for implementers. 

Cheers
Greg

[1] https://github.com/epics-base/normativeTypesCPP/wiki/Normative+Types+Specification
[1.1] https://github.com/epics-base/normativeTypesCPP/wiki/Normative+Types+Specification#display_t
[2] https://epics-controls.org/resources-and-support/documents/pvaccess/
[3] http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes_20150316.html

> On Oct 15, 2021, at 8:53 AM, Cobb, Tom (DLSLtd,RAL,LSCI) via Tech-talk <tech-talk at aps.anl.gov> wrote:
> 
> Hi all,
> 
> We're in the process of writing a pythonSoftIOC that will allow every parameter from a PandABox to be set. It will create the records by introspecting the PandA at startup, then run an IOC which will expose them over CA and PVA (via QSRV). All of the parameter types map to NormativeTypes, but there is more metadata for tables than will fit in the NTTable spec. Specifically:
> 	• All PandA table columns are integer type, but some should be interpreted as enums
> 	• The tables are writeable, and have descriptions, units, low and high limits for each column
> The first could be solved by adding an optional choices structure like enum_t with entries for the columns which are enums and the second could be solved by adding optional display and control structures like NTScalar with entries for each column with this metadata. 
> 
> I could just add these to the IOC, but it would be good to discuss whether it is a good idea with others and make an addition to the normative types document.
> 
> Who would the right people be to discuss this with?
> 
> Thanks,
> Tom
>  
> -- 
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System