Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Mon, 27 Jun 2005 15:35:12 -0500

On Jun 27, 2005, at 2:03 PM, Kay-Uwe Kasemir wrote:

On Jun 27, 2005, at 12:02, Marty Kraimer wrote:

Can it ask for a list of properrtyIds?
...

Given a list of propertyIds how does it obtain the information

associated with each id?

The V4 "client user interface" suggests these in the "DataAccess"

interface:

 	 list<string> getProperties()       Get a list of all the properties
 	 type_info getType(string property)
 	 string getAsString(string property)

I have been looking mostly at the dataAccess tutorial. I should have

looked harder at eh dataAccess header files.

Sorry

Ca accepts a request to get data associated with a propertyId.

Instead of putting it into a caller provided container via the caller

supplied propertyCatalog, CA would make the data available via the

caller supplied dataViewer.

We pretend that the CA client library & data access doesn't hold the

data,

but only presents an interface for the user to copy the data into a
user-provided container.

I am looking at the V4 CA Interfaces document I printed from the wiki

on 6/23. I may be out of date but I dont think so.

It is not clear how a read is performed.

channel.createReadRequest has a propertyCatalogRegistration argument.
What does this describe?

I assumed that it provides a propertyCatalg provided by the caller so

that the CA client libary can use it to put data into a container

provided by the caller.

But I see what you are saying. The read request provides a

readCompletionNotify which has a method

  void success(... , const propertyCatalog &catalog);

This seems to mean that the requester must implement dataViewer so that

it can call catalog.traverse to get the data it wants. Does this means

that the caller must implement all the overloaded reveal methods?

That is all the primitive types, the string segment method, etc. It

would seem that at least the primitive types must be implemented.

If I understand dataAccess, implementing a robust propertyCatalog is a

lot easier than implementing a dataViewer or dataManipulator because of

all the overloaded reveal methods.

Thus I do not understand hoe a read is done.

Well, while you use dataAccess, the CA client library actually holds
the data in some temporary network buffer.
So you don't need a container at all if you only want to get a list
of all the properties & types.

 Does the proposed CA V4 interface allow this?

Yes, Jeff proposes a channel::createAllPropertiesReadRequest.
Does that cover your idea for a simply 'probe'- type application?

     createAllPropertiesReadRequest
     ...
     foreach p ( da->getProperties() )
     {
         display da->getType(p), da->getAsString(p)
     }

... or would you also like to see a request that only
gets the properties and types, without fetching any actual values?

The latter. I think Jeff alluded to this but do not know when.

A primary reason is arrays. If the array is huge, e.g. a many megabyte

image, then it should not be necessary to retrieve the image just to

find out it's properties.

Marty

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System