Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 09 Aug 2001 23:26:41 +0200

Andrew Johnson wrote:
> 
> Benjamin Franksen wrote:
> >
> > Andrew Johnson wrote:
> > >
> > > LINR might be converted to a string field, which would allow the desired
> > > behaviour (and permit the addition of new breakpoint tables at run-time).
> > > Another problem with the enum is that it really should be dynamic
> > > according to the breakpoint tables actually loaded into the IOC, but it
> > > isn't.  However switching to a string will probably break some existing
> > > databases and displays, so I expect it to be rejected.
> >
> > I have thought about a different solution. Reduce menuConvert to a fixed
> > set of general conversion methods, i.e. one of {NO CONVERSION, LINEAR,
> > BREAKPOINT, SUBROUTINE}. A separate (new) field of string type could
> > hold the name of the breakpoint table in case LINR is BREAKPOINT or the
> > name of a subroutine in case LINR is SUBROUTINE.
> 
> This is probably better than just having a string field, but it's not
> completely backwards compatible as a record definition must specify two
> field values to select a particular breakpoint table.  It would also need
> modifications to any displays that used to be able to switch between
> different tables.

True. Somehow this reminds me of the link business. Only that this time
we want it the other way round. More precisely:

With current DTYP and INP/OUT we have in principle exactly what I had in
mind for LINR and the conversion spec field. When dbLoadRecords
encounters a DTYP field (type DBF_DEVICE) it tries to match the string
to one of the device specs that were loaded with the dbd. With
breakpoint tables and subroutines for conversion this would be quite
similar.

But we already learned, that this solution has disadvantages. And we
have something to replace it: your new link type proposal. Maybe the
sort of syntax you proposed for link definitions:

	linktype(param,...)

could be implemented in such a general way, that is is possible (in the
future) to specify LINR field in a similar way:

	bpt(name-of-table)

or

	sub(name-of-subroutine)

What I am thinking of is a field type "extendable menu with optional
attributes" of which link fields would be just a special variant. As
with link fields, for each choice a support module (entry table) must be
specified, that interprets the parameters.

These are just a raw ideas. Maybe it's worth thinking about it.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System