Hi Ricardo,
Kay's and Matt's advice is good.
The best way for you to get started is to look at the examples. I see you've been looking at the Java examples, but I suggest you look at the C++ code too. There are more examples there of what you're trying to do.
Using monitors sounds like the right thing for you to be doing.
For the server-side you should definitely use pvDatabase. This will avoid you having to write a lot of server code. pvDatabaseCPP has been around for a while and a number of people have successfully used it (e.g Kay's neutron server). There are a number of good examples in pvDatabaseCPP. I'd start from exampleServer.
Marty Kraimer's also been developing pvDatabaseJava. Marty said today this is now usable, so if you want to do Java you might try it out, but bear you'll probably be the first real user. I've had a quick look and there are some simple examples there in pvDatabaseJava/example. I've just built it now and given the ExampleDatabase and HelloExample examples a quick try and at a first look these seems to work OK.
You'll have to clone it from SourceForge:
hg clone http://hg.code.sf.net/p/epics-pvdata/pvDatabaseJava
You can get the latest of other modules there too.
There's not a client library yet, but there are a number of examples of clients. There are those in pvAccessCPP (e.g. pvget has a monitored version) as well as those in pvDatabaseCPP. I used longArrayMonitor in arrayPerformance to get started with my clients.
There's also the neutron server/client mentioned and another simple client/server example I wrote, ntndarrayServer, in alphaCPP (clone in the same way as pvDatabaseJava).
Just copy one of the examples and modify the requesters or if you use the client.* code in ntndarrayServer you can create a MonitorCallback and implement the processElement method. ntndarrayServer was just some test code, but it may be a fast way to get going if you're going to do a C++ client.
If you have any more questions I'll be happy to answer them.
Good luck.
Dave
________________________________________
From: [email protected] [[email protected]] on behalf of Kasemir, Kay [[email protected]]
Sent: 24 February 2015 17:02
To: Ricardo Herrero
Cc: <[email protected]>
Subject: Re: Begginer with EPICSv4
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
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
- Replies:
- RE: Begginer with EPICSv4 Ricardo Herrero
- References:
- Begginer with EPICSv4 Ricardo Herrero
- Re: Begginer with EPICSv4 Kasemir, Kay
- Navigate by Date:
- Prev:
RE: Vacuum GUI: Vac. Status and Pumping Procedural Aid Mark Rivers
- Next:
multiple interrupt callback for waveform record Vishnu Patel
- 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 Kasemir, Kay
- Next:
RE: Begginer with EPICSv4 Ricardo Herrero
- 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
|