Experimental Physics and
Industrial Control System

Thanks for all your answers, you solved my doubt. As Steven and Key noted, the client needs additional information to be able to interpret the remote interface. Fortunately this is not the responsibility of the middleware (i.e. EPICS). 

EPICS can implement dynamic communication for monitoring as mentioned by Marty:

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

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.

 

My final questions regarding this topic are:

1. Can I use this introspection interface with C++, Java and Python?

2. Can I use this introspection interface to retrieve the name of a service and its parameter list to compose a RPC during runtime by following Marty's approach?

For example, In a program that I made I used static RPC by hardcoding the name of the service and matching the parameters required (a PVStructure) during development time,

RPCClientImpl client = new RPCClientImpl("control");

...

client.request(pvTelescopeParameters, REQUEST_TIMEOUT);

I understand that using static communication is more straightforward and easy for the developers and will probably be used the 90% of the time. So my question is more theoretical:
Can a client discover the service name (control) and the parameters required to compose the RPC during runtime (dynamic RPC)?

Thanks again for the help, Now I will check the example sent by Mark,

Best regards,

Renato

On Mon, Apr 2, 2018 at 3:21 PM, Kasemir, Kay <[email protected]> wrote:

Hi:

Steve wrote:
> Knowing only the name of the variable, the client can request the structure. For example, using the command-line pvget utility . . .
>$ pvget BL6:Det:Metadata
>BL6:Det:Metadata
>structure
>   time_t timeStamp 2018-04-02T13:32:08.794 19815342
 >   epics:nt/NTScalar:1.0 proton_charge
 >      double value 0
>    epics:nt/NTScalarArray:1.0 time_of_flight
>        uint[] value []
>    epics:nt/NTScalarArray:1.0 pixel
>        uint[] value []
>. . . tells me that the variable BL6:Det:Metadata has a structure consisting of a timeStamp, a NTScalar value for proton_charge, and NTScalarArrays for time_of_flight and pixel.

pvget dumps the structure and shows the values.
If the structure contains arrays with many elements, it might be a bit much to dump on the console.

With "pvinfo" you get just the structure layout, sans values:

$ pvinfo  BL6:Det:Metadata
CHANNEL  : BL6:Det:Metadata
STATE    : CONNECTED
ADDRESS  : ...
structure
    time_t timeStamp
        long secondsPastEpoch
        int nanoseconds
        int userTag
    epics:nt/NTScalar:1.0 proton_charge
        double value
    epics:nt/NTScalarArray:1.0 time_of_flight
        uint[] value
    epics:nt/NTScalarArray:1.0 pixel
        uint[] value


So pvinfo would allow you to inspect the structure, and then you use pvget to fetch the pieces of interest.
As Steve mentioned, to make sense  of the structure you might need additional info.
For instance, you see that "pixel" is an array of uint. But what does that mean?

-Kay

--

Renato Sanhueza Ulsen
Ing Civil Informática.