Experimental Physics and
Industrial Control System

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).

 

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

I greatly appreciate your help

Best regards,

Renato

On Sun, Apr 1, 2018 at 1:41 PM, Johnson, Andrew N. <[email protected]> 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 <[email protected]> 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. <[email protected]> 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 <[email protected].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.