Experimental Physics and
Industrial Control System

"Rees, NP \(Nick\)" <[email protected]> · Fri, 16 Dec 2005 17:05:59 -0000

All,

A few years ago Matej, Andrew and John Maclean defined extensions to the
current EPICS db format to enable VDCT to operate as a hierarchical
database configuration tool. I understand from Andrew that the intention
is that these "template" and "expand" extensions are going to become
standard in the not too distant future. However, recently we have
encountered problems related to limitations in these extensions. For
those who don't know about this, these extensions are documented at:

http://www.cosylab.com/visualdct/builds/VisualDCT/2.4.1257/doc/DES-Visua
lDCT_EPICS_Databases_Hierarchy_Support.html

Part of the problems we experience is due to the confusion about what is
happening at the
template interface. In part, this is due to the conflict between
macros used as text substitution macros and macros used as port macros -
these are subtly different. If a port macro is not resolved then it
shouldn't be an error, I believe it should be treated as if it never
existed in
the first place. If a text substitution macro is not resolved then it
should remain as the macro to be substituted at a later time.

I propose that we clarify this by declaring a port macro as such in
the template declaration. There are then two types of ports - ones
that take data in from above (which is done by string substitution)
and ones that pass data back. While we are at it, I think it would
also be good to declare any string macros used in the template
statement as well. For example:

template() {
# The following creates a port that passes the string "t1" to an upper
level file.
  port( UP, "t1" )
# The following declares a port that, if defined in an upper level
diagram 
  portmacro( DOWN )
# The following declares a string substitution macro.
  macro( STRING )
}

The template statement thus becomes an interface statement (a bit like
the record declaration in a dbd file) and not just means of passing
information up. As such, it should also be possible to attach metadata 
to it (such as a description field).

Statements within the template statement have two
parameters if they pass information up and one parameter if they pass
information down. If macros or port macros appear within the file and
are not declared a warning should be generated.

When a database configuration tool instantiates a template in an upper
level diagram it should define the portmacro's to be null and normal
macros to be propagated. i.e., assuming the above example is in a file
called test.vdb, by default we expand it by the statement:

expand("test.vdb", t4) {
  port( UP )
  portmacro(DOWN, "" )
  macro(STRING, "$(STRING)" )
}

Note that the elements that have two parameters in the template
statement have one parameter in the corresponding expand statement and
vice versa - indicating the direction of data flow across the
interface. Also note that the definition of "$(STRING)" here means
that all string macros declared in lower level diagrams are also
declared explicitly at this level, and so this file's template()
statement need only declare macro's in its own file. At the top level
we have a template() statement that declares all the unresolved macros
in the entire hierarchy.

If you open an existing hierarchy the tool should always check the
interfaces for consistency - validating the expand statements against
their corresponding template statements and prompting the user to
resolve conflicts (or failing with an error, or resolving in a default
way with a message), if any.

As a final note, I thought about growing the template syntax until
it basically becomes something very like a dbd record definition.
However, I think we start to lose flexibility given be the simple
macro substitution idea, so I think it is best to discount it.

I would be interested in hearing peoples responses to this.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System