Hi:
The ChannelRPC, I think, is for the RPC type of protocol interaction, where you write some data and then receive a result, like a remote procedure call.
For the basic 'get' or 'monitor' interactions that are similar to Channel Access you don't use the ChannelRPC.
One example for a custom server and client can be found here: https://github.com/kasemir/EPICSV4Sandbox
On Feb 24, 2015, at 5:46 AM, Ricardo Herrero <[email protected]> wrote:
> Hello all,
>
> I´m a newbie in this environment and I´m trying to understand EPICSv4, I have tried examples HelloWorld and rdbService from example JAVA in the last release from EPICSv4-JAVA. Now I´m trying to make a classical example of a PVServer generating data and clients trying to get it automatically, so I have a pair of questions that maybe you can help me to solve.
>
> First: I think that I should try using Monitor to publish/suscribe for automatic onChange working between a PVServer and a Client, AM I right?
> Second: The General architecture for monitor seems a bit complex to me and I need some help to Undestand it. Here are my thoughts and I want to Know if I´m right or where I´m mistaken:
>
> First you start the client with ClientFactory.start(). In the client side you need to get to a ChannelProvider (in this case "pva"). Then you have to create a Channel from the Provider (but you need a ChannelRequester and I don´t know if I just have to create the object or find it in the net).
> Continuining with the creation of a PVStructure you can then create also the Monitor (But I don´t know if when I create the channel, this channel has to be a ChannelRPC or not). Also, Is the requester of the monitor the same as the requester of the Channel creation?.
They're not the same.
The ChannelRequester is used to learn about connection changes,
the ChannelGetRequester is used to receive the result of a 'get',
and the MonitorRequester is used to receive the monitors.
They're all based on the basic Requester that gets debug messages.
In https://github.com/kasemir/EPICSV4Sandbox/blob/master/neutronsDemoServer/src/neutronClientMain.cpp you can see how I used a virtual base MyRequester in all my requester implementation.
You could create just one
class MyRequesterForEverything : public virtual Requester, public virtual ChannelRequester, public virtual ChannelGetRequester, …
to act as a handler for all requests, if you wanted to do it that way.
> Finally I don´t see the structure of the MonitorElement, and when I create the Monitor, do I have to make a while loop where I write the commando FOR for the monitor and get there the MonitorElement?
The MonitorRequester is called with one or more updates. MonitorRequester::monitorEvent() needs to loop over the received events, because you may get multiples within just one 'network package'.
> In the server side I´m even more lost, as I have seen the createMonitor in ChannelRPC, but I can´t see any of the parameters configuration (such as the term onChange) that it´s mentioned in the documentation about Monitor.
We've so far based all our V4 server code on the pvDatabaseCPP library, where updating a PVRecord will send out the monitors.
Again see the EPICSV4Sandbox or Matt's recent email.
Thanks,
Kay
- Replies:
- RE: Begginer with EPICSv4 david.hickin
- References:
- Begginer with EPICSv4 Ricardo Herrero
- Navigate by Date:
- Prev:
Re: Begginer with EPICSv4 Pearson, Matthew R.
- Next:
RE: Using the EPICS Build/Make system to build kernel modules for linux Jameson Graef Rollins
- 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
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Begginer with EPICSv4 Pearson, Matthew R.
- Next:
RE: Begginer with EPICSv4 david.hickin
- 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
2018
2019
2020
2021
2022
2023
2024
|