User talk:AndrewJohnson

This page contains my notes from the EPICS V4 meetings.

Notes from SLAC Meeting

We Preclude Nothing

EPICS V4 Core

Interface Manager - need something to register and find interfaces.

• Could we generate a hash of the interface definition? Would allow us to compare interfaces and match two.

V4 Driver Interface

• Asyn Driver interfaces are now standardized, and are a good prototype for the V4 driver interface.
• In V4 the record types will directly talk to these driver interfaces.
• Hence device support will disappear in V4

Kay: These queryable interfaces are more like COM, although it seems that there is a difference in that in COM everything implements an interface that you can use to query what other interfaces an object implements.

We currently have interfaces for:

• value interface, for doing I/O and finding out about the value width, includes a "value changed" registration interface used for I/O Interrupt
• connection interface, for connecting/dis-connecting devices
• Address parser? or is that part of connection?

Kay: device support needs to be able to introspect the record it belongs to, to get the scan rate for instance, or the display limits. Solution: give the driver the record's name (or some other record pointer) to allow the driver to use the db access routines to get at this data.

However, don't try to include all of the asyn model into base.

Might use a record with a value field being a Map, which we then use for reading and/or writing device configuration data.

Need to have a standard way to handle "local control" of an output device, where this provides another way to modify output values and we want out record value to be updated when this happens. Very similar to RBV and the initial value setting at init_record time.

APS is responsible for the device/driver interface.

Software Registration

Replacement for registrar() which requires that the code implements a basic interface. Maybe this includes a reference counter, as well as reporting, interface queries?

Redundancy Requirements

Goal: 5 second for fail-over to a backup system

Limit: 15 seconds

Record Support Interface

Most of the existing RSET routines are associated with the CA server interface to records, which go away with Data Access.

Divide records into sub-structures with a named interface, but how to actually use that interface? Nobody has any code that can call through an interface that we don't know about until runtime. Therefor all these "structures with interface" need to implement routines in a standard interface.

Links: Is a link really a struct with a specific interface type? Maybe it's shorthand.

struct with interface name: since record type needs to know interface name to be able to call the interface, why is it being specified in the DBD file, rather than in an interface lookup inside the record code?

We should consider if there's any way to allow asynchronous calls from record routines for stuff other than just device support. This is hard though...

DA Vampire

Allow plugins that get inserted between the records and the CA server, in two places.

• A plugin can insert itself into the server event notification lists for indiviual fields and hence get called in the context of the db_post_event() call (or equivalent) inside the record's process routine.
• The plugin can also add properties to a record's property catalog (or even replace existing properties) and hence change the outside view of the record's fields.

SuperRecords

• Extract the hardware I/O functionality from the AI, BI, etc. records into separate objects that have associated code - init, delete, special, and multiple phases of process (which are named)
• Create a standard wrapper record type that can instanciate a single one of these objects into a record. At process time, this will execute each of the object's process routines in order.
• Be also able to instanciate one or more of these objects into a record type that has its own process routine, which can select which of the sub-object process routines to call in which order.

I agreed (with Bob) to look at this approach for the next core meeting, flesh out the implications for the DB internals etc., how easy would it be to implement this, what it will look like.

Hmm, code segments in the DBD file - can we put the super-record's process routine into the DBD file? Or extract DBD file information out of a .cpp file.

Data Access Layer

Sits above the record layer, presents the CAS with a property catalog interfaced container that contains only those properties that have changed.

Coloured Beam Triggers

Permit a site to enhance the definition of the timestamp, adding an event bitmask field to the storage. The source of the timestamp (event system, TSEL, device support) can now fetch the beam colour as well as the current time. Events are named.

CA Event/Property discussion

We need to develop a table giving the standard events and the properties we expect to send on each event. This would help with understanding and discussions.

• Record and device support must no longer be allowed to write to CA-visible fields themselves; they must go through a wrapper that sets a bit in a bitmap that records a particular field has been changed.
• A record's process() routine starts by resetting the bitmap, then anything changed will be flagged, and at the end we call (something like the current) db_post_event() which notes all of the set bits and flags those changes up to the layer above. This only applies to "dynamic" property fields.
• Changes to record fields that are not "dynamic" only occur due to CA or DB puts; the act of changing the field also causes a db_post_event() for those changes.

How do we map channel names after the dot into the database? I want to allow multiple views into the same record, so the first thing after the dot is the name of a property catalog; different catalogs would give different views of the record - the value catalog, the fields catalog, maybe others.

In the documentation we need to explain where property catalogs come from, and how they replace the old DBR_STS_DOUBLE and similar structures.

Jeff's example code follows. In this, readAdapter has been renamed, but we don't remember what to; we're also missing out epicsGuard locks etc.

class myChannel :
    private propertyCatalog,
    private subscriptionUpdateNotify
{
public:
    myChannel();
private:
    void traverse(readAdapter &);
    void find(readAdapter &);
    void update(epicsGuard &, const eventSpec &, const propertyCatalog &);
    double val;
    double high, low;
    channel &chan;
};

void myChannel::traverse(readAdapter &ra) {
    ra.reveal(valPropId, val);
    ra.reveal(highPropId, high);
    ra.reveal(lowPropId, low);
}

void myChannel::find(readAdapter &ra) {
    ...
}

void update(epicsGuard &, const eventSpec &, const propertyCatalog &in) {
    this->assign(in); // This calls my traverse function above, copying data
}

myChannel::myChannel() :
    chan(channel.makeChannel(args ...)
{
    chan.createSubscriptionRequest(oops, needs ticket from below
}

main() {
    myChannel dummy(oops, can't do this yet);
    propertyCatalogRegistration ticket = 
        registrationFactory::createRegistration(dummy);
}

When we got to this point, we realized that we can't use the myChannel class to do subscriptions, and we abandonded the example.

There are lots of things that can be layered on top of Jeff's API to provide the ability to ask "does this propertyCatalog have this property", or to simplify the task "give me the value as a double".

Core Talk

Convert this to a mailing list, add everyone plus Benjamin and Janet to this list.

Next Meeting

Goal is to be able to start coding after the next, Design meeting, so we have lots to be before then specifiying this lot.

Week of July 11-15, at APS. That's 9 weeks away.

Notes from APS meeting

Ned's Questions:

• Who are the customers?
• What are their requirements?

General Requirements discussion

• No Tornado 2.x
• VxWorks 6.x does not support 68k, so 68k supported only on RTEMS or other OS.
• Memory is still a limitation - 8MB MVME162, 16MB Coldfire minimums.

Upgrade path from V3 will involve the use of Gateways, not backwards compatibility of the CA network protocol. Converters for existing IOC applications will be required, but may target special compatibility database records if the V4 record set is sufficiently different that direct conversion is not possible.

DBD Syntax

method() discussion, not 100% decided.

field attribute prompt => help() text and can be attached to anything, say records etc.

group => ?

for V3 compatibility, we will define a view for each of the old field names, which accesses the new equivalent for the old field.

We need the ability to address something inside a view's property catalog, giving the property hierarchy path after a dot:

caget fred.value.displayLimit.high

3 fundamental value types: analog, enumerated and string. There is major pressure to use different names for the value view of records that are of the different value types.