Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Thu, 19 Feb 2009 15:40:36 -0500

I will agree with Jeff that adding new types to db_access.h and

implementing them is not an easy or desirable thing to do.

However I suggest that the way the JavaIOC handles data solves the

problem. The current implementation is in Java but support for the same

data types could be implemented in C++

I have attached the overview document for a new project called pvData.

pvData is the the next version of the data portion of the JavaIOC. The

xml syntax is completely different (due to comments from Matej and

Andrew). The types are simplified due to discussions with Matej. The

pvData project has what is required for data handling and can be used by

more than the JavaIOC. The next release of the JavaIOC will use pvData

instead of pvData being part of the javaIOC.

Marty

Jeff Hill wrote:

*6. CA Support for "Our ArchiveRecord" and Others*
The DESY archive record samples "value, time and severity" into an array
of structures. Unfortunately we can not pass this array over channel
access directly (as far as I know). So we have additional arrays with
value (double), seconds_epoch (ulong), nanoseconds (ulong) and severity
(short). It would be better and more safe (locking is not provided well
now) if we could use something like an array of
"DBR_TIME_DOUBLE_STAT_SEVR (or so).

I will leave Jeff Hill to comment on the feasibility of adding new request
types like this and the idea below to CA.

The quick answer is that there are two ways to do this.

1) We certainly can code new data types into the db_access data model. The primary obstacle to overcome, when satisfying your request, will be that CA and db_access both currently expect that arrays occur only with the value field, and that the value field is always the last field in the structure. Thus, making arrays of DBR_TIME_DOUBLE_STAT_SEVR tends to break data model consistency in a number of important places. In the CA client API, CA client library, in the CA protocol, in the CA server, and in the database library. I think that an inconsistent approach to arrays in the legacy CA client API is what we might be most fearful of. Furthermore, I think it's safe to say that the scale of the changes in the base codes is not making this appropriate for an R3.14 patch.

2) So it appears that we need a better API and when we make that jump it's important to adopt a flexible approach which will accommodate future needs. What we really need is more flexible APIs so we can have generalized client and service specified formats for aggregating data. I have written a design document (it's on the wiki) describing a new protocol that can have this level of flexibility, but for R3.15 we are concentrating only on new flexibility allowing service specified formats for aggregating data on the server's (IOC's) event queue, and on an ability for clients to specify in their subscriptions generic filtering expressions that test service specific parameters determining which subscription updates will be sent. We admit to being strongly requirements driven for our upgrade here at LANSCE, but nevertheless we are committed to a very general approach which should have excellent utility for the community.

To summarize, the db_access data model has many severe constraints, but changing the model to make its approach to arrays inconsistent may not be a great strategy, and making large changes in R3.14 probably isn’t a robustness enhancing strategy either. From my perspective, the Data Access library is the proper flexible, runtime bound, API for accessing client/service specified data aggregation formats that we will need in the future. Furthermore, wire protocol flexibility for client / service specified data formats is not on the short list, but event queue flexibility and API flexibility is. Once the near term event queue goals and API upgrades are done, then wire protocol flexibility looks like a logical next step. I admit to working specifically on LANSCE's immediately needs for its upgrade, and while protocol flexibility is certainly going to be very useful here it hasn’t been given as high a priority near term as the event queue changes.

Jeff

public enum Type {
    scalar,
    scalarArray,
    structure;
}

public enum ScalarType {
    pvBoolean,
    pvByte,pvShort,pvInt,pvLong,
    pvFloat,pvDouble,
    pvString;
    // The following are convenience methods
    public boolean isInteger();
    public boolean isNumeric()
    public boolean isPrimitive() 
    public static ScalarType getScalarType(String type);
}
public interface Field extends Serializable {
    String getFieldName();
    Type getType();
}

public interface Scalar extends Field{
    ScalarType getScalarType();
}

public interface Array extends Field{
    ScalarType getElementType();

}

public interface Structure extends Field{
    String[] getFieldNames();
    Field getField(String fieldName);
    int getFieldIndex(String fieldName);
    Field[] getFields();

}
public enum MessageType {info,warning,error,fatalError}

public interface Requester {
    String getRequesterName();
    void message(String message, MessageType messageType);
}

public interface Serializable {
    void serialize(ByteBuffer buffer);
    int getSerializationSize();
    void deserialize(ByteBuffer buffer);
}

public interface PVAuxInfo {
    PVField getPVField();
    PVScalar createInfo(String key,ScalarType scalarType);
    Map<String,PVScalar> getInfos();
    PVScalar getInfo(String key);
}

public interface PVField extends Requester, Serializable {
    Field getField();
    PVStructure getParent();
    PVRecord getPVRecord();
    String getFullFieldName(); 
    String getFullName();
    PVAuxInfo getPVAuxInfo(); //auxillary information
    boolean isMutable();
    void setMutable(boolean value);
    void replacePVField(PVField newPVField);
    // following methods are for monitoring changes
    boolean addListener(PVListener pvListener);
    void removeListener(PVListener pvListener);
    void postPut();
}
public interface PVDouble extends PVScalar{
    double get();
    void put(double value);
}
public interface PVArray extends PVField{
    Array getArray();
    int getLength();
    void setLength(int len);
    int getCapacity();
    void setCapacity(int len);
    boolean isCapacityMutable();
    void setCapacityMutable(boolean isMutable);
}
public class DoubleArrayData {
    public double[] data;
     public int offset;
}

public interface PVDoubleArray extends PVArray{
    int get(int offset, int len, DoubleArrayData data);
    int put(int offset,int len, double[] from, int fromOffset);

}
public interface PVStructure extends PVField {
    Structure getStructure();
    PVField[] getPVFields();
    PVField getSubField(String fieldName);
    boolean replaceStructureField(String fieldName,Structure structure);
    void appendPVField(PVField pvField);
    void postPut(PVField subField);
    // The following are convenience methods
    PVBoolean getBooleanField(String fieldName);
    PVByte getByteField(String fieldName);
    PVShort getShortField(String fieldName);
    PVInt getIntField(String fieldName);
    PVLong getLongField(String fieldName);
    PVFloat getFloatField(String fieldName);
    PVDouble getDoubleField(String fieldName);
    PVString getStringField(String fieldName);
    PVStructure getStructureField(String fieldName);
    PVArray getArrayField(String fieldName,ScalarType elementType);

}
public interface FieldCreate {
    Scalar createScalar(String fieldName,ScalarType scalarType);
    Array createArray(String fieldName,ScalarType elementType);
    Structure createStructure(String fieldName, Field[] field);
}
public interface PVDataCreate {
    PVField createPVField(PVStructure parent, Field field);
    PVScalar createPVScalar(PVStructure parent,Scalar scalar);
    PVScalar createPVScalar(PVStructure parent,String fieldName,
        ScalarType fieldType);
    PVArray createPVArray(PVStructure parent,Array array);
    PVArray createPVArray(PVStructure parent,String fieldName,
        ScalarType elementType);
    PVStructure createPVStructure(PVStructure parent,String fieldName,
        Field[] fields);
    PVStructure createPVStructure(PVStructure parent,String fieldName,
        PVStructure structToClone);
    PVStructure createPVStructure(PVStructure parent,String fieldName,
         PVDatabase pvDatabase,String structureName);
    PVRecord createPVRecord(String recordName,Field[] fields);
    PVRecord createPVRecord(String recordName,PVStructure structToClone);
    PVRecord createPVRecord(String recordName,PVDatabase pvDatabase,
         String structureName);
}
    interface PVRPC {
        PVString methodName;
        PVStructure arguments;
        PVStructure result;
    }
Copyright (c) 2008 Martin R. Kraimer
Copyright (c) 2006 The University of Chicago, as Operator of Argonne
     National Laboratory.
Copyright (c) 2006 Deutsches Elektronen-Synchroton,
     Member of the Helmholtz Association, (DESY), HAMBURG, GERMANY.
Copyright (c) 2007 Control System Laboratory,
    (COSYLAB) Ljubljana Slovenia

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

________________________________________________________________________

This software is in part copyrighted by the University of Chicago (UofC)

In no event shall UofC be liable to any party for direct, indirect,
special, incidental, or consequential damages arising out of the use of
this software, its documentation, or any derivatives thereof, even if
UofC has been advised of the possibility of such damage.

UofC specifically disclaims any warranties, including, but not limited
to, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement.  This software is provided on an "as is"
basis, and UofC has no obligation to provide maintenance, support,
updates, enhancements, or modifications.

________________________________________________________________________

This software is in part copyrighted by the BERLINER SPEICHERRING
GESELLSCHAFT FUER SYNCHROTRONSTRAHLUNG M.B.H. (BESSY), BERLIN, GERMANY.

In no event shall BESSY be liable to any party for direct, indirect,
special, incidental, or consequential damages arising out of the use of
this software, its documentation, or any derivatives thereof, even if
BESSY has been advised of the possibility of such damage.

BESSY specifically disclaims any warranties, including, but not limited
to, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement.  This software is provided on an "as is"
basis, and BESSY has no obligation to provide maintenance, support,
updates, enhancements, or modifications.

________________________________________________________________________

This software is in part copyrighted by the Deutsches Elektronen-Synchroton,
    Member of the Helmholtz Association, (DESY), HAMBURG, GERMANY.

In no event shall DESY be liable to any party for direct, indirect,
special, incidental, or consequential damages arising out of the use of
this software, its documentation, or any derivatives thereof, even if
DESY has been advised of the possibility of such damage.

DESY specifically disclaims any warranties, including, but not limited
to, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement.  This software is provided on an "as is"
basis, and DESY has no obligation to provide maintenance, support,
updates, enhancements, or modifications.
________________________________________________________________________

Experimental Physics and
Industrial Control System

EPICS PVData
Overview
2009.02.19

Introduction

Interface Definitions

Types

Introspection Interfaces

Data Interfaces

Introspection and Data creation

PVData Conversion

Package Summary

{@link org.epics.pvData.pv}

{@link org.epics.pvData.factory}

{@link org.epics.pvData.property}

{@link org.epics.pvData.xml}

{@link org.epics.pvData.misc}

{@link org.epics.pvData.test}

Unresolved Issues

Property

Attribute

Remote Procedure Call

License Agreement

Experimental Physics and Industrial Control System

EPICS PVData Overview 2009.02.19

Introduction

Interface Definitions

Types

Introspection Interfaces

Data Interfaces

Introspection and Data creation

PVData Conversion

Package Summary

{@link org.epics.pvData.pv}

{@link org.epics.pvData.factory}

{@link org.epics.pvData.property}

{@link org.epics.pvData.xml}

{@link org.epics.pvData.misc}

{@link org.epics.pvData.test}

Unresolved Issues

Property

Attribute

Remote Procedure Call

License Agreement

Experimental Physics and
Industrial Control System

EPICS PVData
Overview
2009.02.19