Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 5 Dec 2016 17:28:46 -0600

Hi Tim,

On 12/05/2016 04:45 PM, Madden, Timothy J. wrote:
> Say we wish to make PVs that are more than soft PVs. There seems to be
> more than one way to make a PV do something.

That is a common pattern with EPICS, we like to give you choices...

> Example: We put a 1 to an int PV, and the server
> writes something to an instrument.
> 
> How do we do this? It seems like there are several ways:
> 1) Use a monitor client like seq does.

Possible, but not really the intended approach.

> 2) extend PVRecord and fill in the process() function. Not sure how to
> get all the data we need.

You would add fields to the record for the inputs and outputs you want
it to have, then implement all of the behaviours it needs. Note that
using a PVRecord is probably analogous to writing your own record type
in the V3 IOC, but it doesn't have the same underlying IOC database
structure and device support layers, or the ability to link records
together AFAIK (I could be wrong about that).

> 3) use this RPC business, extending a PVRecord.

You can write an RPC client and server without having to use PVRecord as
the basis for your code, look at helloRPC in exampleJava for a simpler
example. I don't think Control System Studio has much if any direct
support for channelRPCs though, so if you're planning on using that for
a GUI your server might also need to provide regular channels for status
reporting and control.

If you haven't already you should check out the exampleJava source code
from https://github.com/epics-base/exampleJava — the exampleJava and
exampleCPP modules contain a number of template-type applications for
study and building on.

> 4) What about adding a PVListener to PVRecord? I could not figure this
> out. The idea is that PVListener
> would make the instrument do something, and we need not extend PVRecord.
> 
> What is the preferred design for making a PV do something in a server?

I'm going to leave those questions for Marty Kraimer to answer, I don't
really know the internal details myself...

> General question:
>  I know RPC stands for remote procedure call, but what does it mean in
> epics V4?

Remote Procedure Call. The difference between a pvAccess putGet and a
channelRPC is that the client gets to decide what kind of argument(s) to
send with a channelRPC, whereas for a putGet operation the structure of
the put data is determined by the channel itself (you can introspect it
through the pvAccess API, whereas with the channelRPC the client
currently has to know what types the server will accept).

> What does it do that epics V3 does not do? Is this just a fancy name for
> record support?

No, channelRPC is a new mechanism which was not present in Channel
Access. The best analogy is that it lets you send a command with all of
the parameters necessary for it in a single (atomic) operation, and get
back the response with all its results. With the V3 record design you
can't stop two or more clients from fighting over control of the same
instrument by writing to different fields of its record. A channelRPC
permits the server to handle each client in turn without them
interfering with each other (assuming the server and/or the instrument
can do that).

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System