Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 14 Aug 2001 20:59:11 +0200

Hello Andrew, Bob, Marty, Russel and all the others.

Most of my recent remarks regarding the issue of analog conversion were
premature and sometimes confused. I want to apologize and ask you to
forget about them. Instead, I'd like you to consider a new proposal,
which I arrived at after taking into account the (justified) critique of
previous ones.

This approach is at once scalable, flexible and yet almost completely
backward compatible. No additional record fields are involved. It
requires (of course) changes in the analog record supports and -
depending on how far we want to go with this - minor additions to the
ioc core.

It goes like this:

Currently the field LINR of the analog records is of type DBF_MENU. That
means the choices are taken from a menu definition, in this case
"menuConvert". What I propose now, is to change the field type to
DBF_ENUM so that responsibility for providing the choice strings is
moved to the standard record support function get_enum_strs().

For the field LINR, analog record supports will provide the first three
choices according to the definitions in menuLinr.dbd. Currently, this
menu contains the choices NO_CONVERSION and LINEAR. In addition,
menuLinr will have a third choice LINEAR_MANUAL (if anybody can think of
a better name, please come forward with it!), indicating that the user
wishes to configure linear conversion by giving ESLO and EOFF directly,
instead of EGUF and EGUL. New device supports may decide (only in this
case, of course) to calculate EGUF & EGUL from ESLO & EOFF instead of
doing it the other way around (as is usually done).

Additional choices are added as follows:

All breakpoint tables defined in the dbd file are stored in a list
inside the database. That means record support can access them and
present their names as addditional choices to CA clients. No menu
definition has to be replaced or extended or whatever.

In principle we could stop here: We get rid of menuConvert and are able
to specify ELSO and EOFF directly without breaking device supports and
without adding fields.

If we want to go further, the next step is to allow subroutines for
special conversion (the more I think about it, the more I like the
idea). For this, the dbd format needs to be extended. A very simple
syntax could be

	conversion_subroutine(name-of-routine)

A more advanced approach would (1) unify this notion with the
specification of breakpoint tables and (2) allow for additional
parameters to the subroutine (these two extensions are independent).
Breakpoint tables would be specified as

	conversion(breaktable,"name-of-breaktable") {
		values...
	}

[BTW: The current way to specify a breakpoint table could be supported
for backward compatibility, although automatic conversion of dbd files
would be a straight forward matter (a one-line perl script would do).]

Subroutines would be specified as

	conversion(subroutine,"name-of-routine") {
		additional parameters...
	}

or alternatively (I am not yet sure which is better)

	conversion(subroutine,"name-of-routine(additional-parameters...)")

or (yet another approach)

	conversion(subroutine,"name-of-routine","additional-parameter",...)

Maybe additional parameters to conversion subroutines are not really
necessary. If we want to have that feature, we have to agree on some
fixed type for them (double?). The presentation of subroutine choices
should include the additional parameters as a comma separated list in
parentheses after the name of the subroutine. Invocations with different
arguments would then appear as different choices.

Choices for field LINR would then look like this:

	NO CONVERSION
	LINEAR
	LINEAR_MANUAL
	typeKdegF
	typeKdegC
	...(more breakpoint tables)
	subCvtXyToAbc(2,0)
	subCvtBlaToBlob()
	...(more subroutines)

Special conversion routines should be defined in C source-code as

long name-of-routine(double *pval,short linr,short init,
	void **ppbrk,short *plbrk <additional-parameters>)

Resemblance to the declarations for cvtEngToRawBpt and cvtRawToEngBpt in
cvtTable.h is not accidental. There is no reason why the fields INIT,
LBRK and PBRK should not be used by conversion subroutines. Maybe it
makes sense to rename PBRK to CPVT (Conversion Private) and LBRK to LCPT
(Last Conversion Point) in order to reflect their generalized nature. No
compatibility issue is involved because these fields are not
configurable.

Nothing is perfect. There is one minor problem that this proposal would
present: Intelligent DCTs (I mean those that present the user with the
correct choices for menu fields, i.e. everything except CapFast and the
plain text editor) would have to be adapted, since LINR choices will no
longer be taken from a simple menu definition. DbStaticLib should be
extended to support this with a new function named, for instance,
dbGetConversionChoices. This would also simplify the additional code in
the analog record supports.

If we can agree on one or the other version of this proposal (assuming I
haven't again overlooked any major obstacles rendering all of this
useless... anyway) I am willing to do the necessary changes and/or
additions to the record supports and the epics core (and test them).

Ben
-- 
Berliner Elektronenspeicherring-Gesellschaft für Synchrotronstrahlung
(BESSY) GmbH, Control System Group
Albert-Einstein-Straße 15, 12489 Berlin, +4930 6392 8462, www.bessy.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System