EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: question about pvAccess monitor
From: renato sanhueza <[email protected]>
To: "Kasemir, Kay" <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Mon, 2 Apr 2018 17:29:43 -0300
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.

Replies:
Re: question about pvAccess monitor Marty Kraimer
References:
question about pvAccess monitor renato sanhueza
Re: question about pvAccess monitor Johnson, Andrew N.
Re: question about pvAccess monitor Mark Rivers
Re: question about pvAccess monitor Johnson, Andrew N.
Re: question about pvAccess monitor renato sanhueza
Re: question about pvAccess monitor Marty Kraimer
Re: question about pvAccess monitor renato sanhueza
Re: question about pvAccess monitor Hartman, Steven M.
Re: question about pvAccess monitor Kasemir, Kay

Navigate by Date:
Prev: Re: question about pvAccess monitor Mark Rivers
Next: Simple channel access write program within Qt Abdalla Ahmad
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: question about pvAccess monitor Mark Rivers
Next: Re: question about pvAccess monitor Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 03 Apr 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·