Experimental Physics and
Industrial Control System

<[email protected]> · Tue, 24 Feb 2015 19:41:35 +0000

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System