Re: question about pvAccess monitor

[Marty Kraimer <mrkraimer@comcast.net>]

On 04/02/2018 12:28 PM, renato sanhueza wrote:

Hi Marty,

Maybe I didn't express myself correctly, but I was asking for the scenario in which the client doesn´t know a priori the details about the server that it wants to monitor (e.g. it might be a thermometer, a power supply, a fan, an antenna, etc). So I am not able to create the request as you suggested:

PVStructure pvRequest(CreateRequest::createRequest("value,alarm,timeStamp,display,control,valueAlarm"));

Because beside those generic fields a fan can also have others like "speed", "power", etc. which might be different from the fields of an antenna (position, angle, etc). In this scenario, the solution I propose is to send a null request that returns the whole PVStructure of the server to the client. Then the client should determine if the data was received from an antenna, a fan, a thermometer or a power supply so it can react accordingly. To do this the metadata support is very useful, because it would work like XML, the client might understand the message from and unknown server.

So the question is:
 
Can a client use metadata to understand a message from an unknown server? (known as dynamic communication)
Or the software developer has to known the structure of the server to make the client (static communication)   

For pvAccess the client can get the introspection interface for the pvStructure associated with a channel.
It is obtained via a call to

getField()

virtual void epics::pvAccess::Channel::getField	(	GetFieldRequester::shared_pointer const &	requester,
		std::string const &	subField
	)

virtual

Initiate a request to retrieve a description of the structure of this Channel.

While the type described by calls to getField() should match what is provided for all operations except RPC.

GetFieldRequester::getDone() will be called before getField() returns, or at some time afterwards.

Parameters

Requester	The Requester.
subField	Empty string, or the field name of a sub-structure.

It can do this only after it has connected to the channel.
If an empty string is specified for subField then  what the client receives is the introspection interface
for the top level PVStructure for the channel.

The client can then use this introspection interface to compose a request string for creating a  channelGet, ..., monitor.

If this is does not answer your question then maybe someone else can help.

Marty

I know this is a very theoretical question, but it is very important to me. Hopefully someone can help me.

Best regards,

Renato

 

On Mon, Apr 2, 2018 at 7:29 AM, Marty Kraimer <mrkraimer@comcast.net> wrote:

On 04/01/2018 03:28 PM, renato sanhueza wrote:

Thanks for the answers! I was checking more details about the pvRequest field in http://epics-pvdata.sourceforge.net/informative/pvRequest.html and I have two more questions about monitors:

1. Does EPICS support some kind of metadata for building a generic monitor? For example, I want to create a client that is able to monitor any component of the system. The only information that this generic client has are the channel names of the components while the pvRequest object is left null so the entire top level structure of the PVRecord is sent back to the client. Finally the generic client, using metadata or another mechanism like reflection, might be able to understand the message and act accordingly (e.g. if the monitored component was a thermometer then the client can update a certain item in the GUI).

For most PVRecords a field named value provides the most important data.

pvData (both pvDataCPP and pvDataJava) define the following special fields:
enum, alarm, timeStamp, display, control, and alarmLimit.

enum is just a special type of value field.

The other special fields can be considered metadata, i.e. they provide additional information about the value field.
A particular PVRecord can optionally support an arbitrary subset for the special fields.
Most will support timeStamp and alarm.

If you create a request like:
PVStructure pvRequest(CreateRequest::createRequest("value,alarm,timeStamp,display,control,valueAlarm"));

Then you are asking for  the value data and all supported "metadata".

Note that normative types support the special fields.

I encourage You to read
http://epics-pvdata.sourceforge.net/informative/developerGuide/developerGuide.html
Especially
http://epics-pvdata.sourceforge.net/informative/developerGuide/developerGuide.html#special_fields

 

2. What are the advantages and disadvantages of using smart records (pvDatabase) instead of pvAcccess servers? How should I choose between them?

From
http://epics-pvdata.sourceforge.net/informative/developerGuide/developerGuide.html#overview:_pvdatabase
It says:
A framework for implementing a network accessible database of smart memory resident records. Network access is via pvAccess. The data in each record is a top level PVStructure as defined by pvData. A complete implementation of ChannelProvider is provided for accessing the records. The framework can be extended in order to create record instances that implement services. The minimum that an extension must provide is a top level PVStructure, a record name, and a process method.

The important words are that it provides a compete implementation of ChannelProvider.
This is not easy to do correctly.

Mark Rivers referenced components of areaDetector that use both PVRecord and also client code.

I also encourage You to download and look at
https://github.com/epics-base/exampleCPP

It has many examples of both client and server code.
Look first at exampleCPP/database for server code that implements PVRecords.
Look first at exampleCPP/exampleClient for client code examples.

The other examples provide both client and server examples.

Hope this helps.

Marty Kramer

I greatly appreciate your help

Best regards,

Renato

On Sun, Apr 1, 2018 at 1:41 PM, Johnson, Andrew N. <anj@aps.anl.gov> wrote:

I should have also added that almost anything you can do in C++ you should also be able to do using pvaPy, which is implemented as a layer on top of the C++ code. If there are features missing from the Python API that you need it should be relatively straightforward to add them. Python does make it easy to create servers and client applications including ones using pyQt.

- Andrew

--
Sent from my iPad

> On Apr 1, 2018, at 3:20 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:
>
> The EPICS areaDetector project has examples of:
>
> pvAccess server,  NDPluginPva, written in C++. It is in the ADCore repository.
>
> pvAccess client, pvaDriver, written in C++. It is in the pvaDriver repository.
>
> pvAccess client, NTNDArray_Viewer, written in Java. It is in the ADViewers repository.
>
> EPICS_NTNDA_Viewer and pvaDriver both work fine with NDPluginPva.
>
> https://github.com/areaDetector.
>
> Mark
>
>
> Sent from my iPhone
>
>> On Apr 1, 2018, at 5:44 AM, Johnson, Andrew N. <anj@aps.anl.gov> wrote:
>>
>> Hi Renato,
>>
>> Monitors for pvAccess were based on the ideas originally developed for Channel Access, although there has been a little parallel evolution that has yet to be recombined.
>>
>> 1. A pvAccess channel name is the name of a top-level object, meaning that its value is usually going to be a structure with at least some and possibly many sub-fields. One function of the pvRequest object is to provide information about which subset of that top-level object you want to monitor. There are other uses for it, and if you are writing your own server code you can use it to pass additional information from the client at connection time. IIRC there is some documentation about it associated with the pvget command-line program.
>>
>> 2. The two language implementations (C++ and Java) are supposed to be able to interoperate perfectly, so if you come across parts that don’t we want to know about them. There could be some features of individual servers that are only available on one side though, for example there is no Java equivalent of the IOC database.
>>
>> HTH,
>>
>> - Andrew
>>
>> --
>> Sent from my iPad
>>
>>> On Apr 1, 2018, at 5:51 AM, renato sanhueza <renato.sanhueza@alumnos.usm.cl> wrote:
>>>
>>> Hi EPICS community, I am trying to understand how the monitors of pvAccess work. I have a few quick questions, hopefully someone can help me :)
>>>
>>> 1) What information does the monitor need about the monitored component to create the connection between them? I noticed in an example provided in Github that the monitor use a channelName (I assume that it is for the UDP broadcast name resolution mechanism) and a pvRequest string (which I don't understand)
>>>
>>> 2) Can a C++/Java/Python component monitor another one regardless its implementation language?
>>>
>>>
>>> Best regards,
>>> Renato
>>> --
>>> Renato Sanhueza Ulsen
>>> Ing Civil Informática.

--

Renato Sanhueza Ulsen
Ing Civil Informática.

--

Renato Sanhueza Ulsen
Ing Civil Informática.