Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Mon, 18 Aug 2014 10:46:57 -0400

On 08/18/2014 09:45 AM, Ralph Lange wrote:
> Just thinking aloud...
> 
> I remember a number of situations where users were complaining about not 
> being able to set array data from within the .db file. (To specify 
> default values for waveform or compress records.)

Yes this would be nice.

Practically speaking, autosave takes are of most of these cases.  At
NSLS2, several devices take array input (function generators of one kind
or another).  Here a default of an empty, or all zeros, array is acceptable.

> Right now I am facing (reviewing) design documents of device support for 
> a very versatile card that supports routing its inputs and outputs to a 
> multitude of PCI/PCIe backplane signals. Stuff that cries for mbbi/mbbo 
> type records that are not limited to 16 states. If option strings, 
> values, severities were arrays, such records might be fairly easy to 
> implement.

For the mrfioc2 driver I had to deal with this problem (as you may
remember ;).  The workaround was to have three mbbi/o records and a
combination of UNSV and IVOA to handle some of the ~30 possibilities in
each mbbo.

> Has extending the DB syntax to cover array data been considered at some 
> point?

One of changes I'm considering (after the linking/locking work) is to
re-write the DBD file parser.

The idea would be to parse into an intermediate structure which would be
more general than dbStatic.  This would define points in the syntax for
future expansion, and avoid some of the chicken and egg problems of the
present code.

For this specific use case, the intermediate structure would provide an
obvious place to keep the original field value text.  Of course this
tracking could also be grafted on to dbRecordNode as the info() tags where.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System