Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Tue, 03 Dec 1996 13:04:39 -0600

Some more thoughts on hardware configuration.

The following is based on one major change to the 3.13 method
for defining ioc databases as described in chapter 4 of the
3.13 Applications Developer's Guide.

The change is:

The DB_XXXLINK fields will refer to a table of information rather
than the info contained in a DBLINK structure.

Discussion via examples:

Presently record types are defined via the syntax

recordtype(xxx) {
        field(NAME,DBF_STRING)
        ...
}

This is replaced by:

table(xxx) {
        field(NAME,DBF_STRING)
        ...
}

The change from recordtype to table is made to emphasize that
the change above results in ioc databases being similar
to the relational model.

Lets start with a simple example. Lets take an ai record
connected to a VME_IO input.

The following defines the VME_IO table

table(VME_IO) {
    field(card,DBF_USHORT) {
        prompt("card")
        promptgroup(GUI_INPUTS)
    }
    field(signal,DBF_USHORT) {
        prompt("signal")
        promptgroup(GUI_INPUTS)
    }
}

A record instance is defined as follows:

record(ai,xxx) {
    ...
    field(INP,"VME_IO") {
        field(card,"1")
        field(signal,"2")
    }
    ...
}
DBF_INLINK, DBF_OUTLINK, and DBF_FWDLINK fields are all
handled in a similar manner, i.e. in record instances the field value
specified the name of a table and the fields of the table are
recursively
defined.

Now lets give an example that provide more functionality.

We want to be able to configure the vme addresses for a module.
In addition each channel can have an individual gain.
Lets define two additional tables: the first contains definitions for
the card. The other contains definitions for configuring a channel.

table(xxxAdc) {
        field(name,DBF_STRING) {
                prompt("Record Name")
                special(SPC_NOMOD)
                size(29)
        }
        field(card,DBF_ULONG) {
                prompt("VME Slot")
                promptgroup(GUI_INPUT)
        }
        field(a24o,DBF_ULONG) {
                prompt("A24 Offset")
                promptgroup(GUI_INPUT)
        }
        field(a24l,DBF_ULONG) {
                prompt("A24 Length
                promptgroup(GUI_INPUT)
        }
        ...
}

table(xxxAdcChannel) {
        field(xxxAdcName,DBF_STRING) {
                prompt("xxxAdc Record Name")
                promptgroup(GUI_INPUT)
        }
        field(signal,DBF_USHORT) {
                prompt("Signal")
                promptgroup(GUI_INPUT)
        }
        field(gain,DBF_MENU) {
                prompt("Gain")
                promptgroup(GUI_INPUT)
                menu(menuXxxAdcGain)
        }
        ...
}

A record is defined as

record(mycard,xxxAdc) {
        field(name,"xxxAdcCard1")
        field(card,"1")
        field(a24o,"0x00a000")
        field(a24l,"0x1000")
}

record(xxx,ai) {
        ...
        field(INP,"xxxAdcChannel") {
                field(xxxAdcName,"xxxAdcCard1")
                field(signal,"2")
                field(gain,"10x")
        }
        ...
}

This example demonstrates that it will be possible to provide arbitrary
configuration information.

A comment:
We could add a new field type DBF_TABLE. Thus provides a "substructure"
capability

Now lets discuss how the three different viewpoints of epics databases,
i.e. DCT tools, Channel Access, and record/device access.

DCT Tools:

Since links are handled in a uniform manner, I maintain that this method
will be easier for all configuration tools.

CA Clients:

DBR_TABLE is a new request type. It's value is the table name returned
as a string. A new CA request, DBR_TABLE_FIELDNAMES,
will return the complete set of field name for a table.

A client can access the table field itself or fields within a table.
Using the first example above

xxx.INP has native type DBR_TABLE and value "VME_IO".
xxx.INP.card has native type DBR_USHORT and is accessed like
any other DBF_USHORT field.

iocCore, record suport, device support:

The dbToRecordTypeH utility will be renamed to dbToTableH, i.e.
a c structure can be generated for any table. All code that
intimately uses the information in a table should use the generated
structures. Note that except for a few special table types iocCore
will NOT include the generated structure definitions.

Currently all recordtype definitions include dbCommon.dbd, i.e.
all the fields in database common. As a first guess I think there
should be 3 flavors of fields to replace database common:

0) No fields. A table instance has no separate existance outside
the record instance field within it exists. No record methods defined.
The purpose of this flavor is to allow device/drivers access to
configuration information without the requirement of providing methods
for allowing CA to access the information.
1) Fields that allow channel access connections. Record methods are
defined for CA interaction. Database scanning not supported.
2) All fields in current database common. Identical to existing
recordtypes.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System