Skip to content

PV Access gateway/proxy and EPICS Process Database integration

License

Notifications You must be signed in to change notification settings

epics-base/pva2pva

Folders and files

NameName
Last commit message
Last commit date

Latest commit

3a08da4 · Dec 13, 2023
Mar 12, 2021
Dec 20, 2019
Jun 22, 2022
Jun 2, 2020
Dec 13, 2023
Dec 13, 2023
Nov 3, 2022
Jun 2, 2020
Sep 14, 2023
Oct 26, 2022
Mar 12, 2021
Nov 30, 2017
Dec 20, 2019
Sep 6, 2019
Dec 13, 2023
Sep 28, 2017
Apr 6, 2018
Aug 30, 2020
Feb 17, 2016
Oct 5, 2018

Repository files navigation

See main documentation page.

This repository contains two distinct pieces of software.

QSRV

A PV Access (protocol) server to be included in an EPICS IOC.

myioc_DBD += qsrv.dbd
myioc_LIBS += qsrv

For convenience an executable `softIocPVA' is also built which is equivalent to the 'softIoc' executable from EPICS Base with the addition of QSRV.

p2p

A PV Access gateway (aka proxy). The 'p2p' executable.

The P2P gateway has been deprecated in favor of p4p.gw.

Dependencies

or bundled with

Building

To build all dependencies from source:

git clone --recursive https://github.com/epics-base/epics-base.git
make -C epics-base

Running QSRV

Any IOC which includes QSRV will automatically start a PV Access server which exposes all channels (aka. "recordname.FLD") in the same manner as the built-in Channel Access (protocol) server.

QSRV Group Definitions

The following .db file snippet defines a group PV "grp:name" to have two sub-structures "A" and "B". Each sub-structure encodes the value and meta data one PV. eg. "recname.VAL" is stored in "grp:name.A" and "other.VAL" is "grp:name.B".

record(longin, "recname") {
    info(Q:group, {
        "grp:name":{
            "A":{
                +channel:"VAL"
            }
        }
    })
}
record(longin, "other") {
    info(Q:group, {
        "grp:name":{
            "B":{
                +channel:"VAL"
            }
        }
    })
}

A full list of info(Q:group options.

record(...) {
    info(Q:group, {
        "<group_name>":{
            +id:"some/NT:1.0",  # top level ID
            +meta:"FLD",        # map top level alarm/timeStamp
            +atomic:true,       # whether monitors default to multi-locking atomicity
            "<field.name>":{
                +type:"scalar", # controls how map VAL mapped onto <field.name>
                +channel:"VAL",
                +id:"some/NT:1.0",
                +trigger:"*",   # "*" or comma seperated list of <field.name>s
                +putorder:0,    # set for fields where put is allowed, processing done in increasing order
            }
        }
    })
}

Running p2p

pva2pva gateway is intended for use on a computer with at least two ethernet interfaces. At present each pva2pva process can act as a uni-directional proxy, presenting a pvAccess server on one interface, and a client on other(s).

The file loopback.conf provides a starting point.

At present there are no safe guard against creating loops where a gateway client side connects to its own server side. To avoid this ensure that the address list does not contain the interface used for the server (either directly, or included in a broadcast domain). EPICS_PVA_AUTO_ADDR_LIST must remain set to NO.

cd pva2pva
./bin/linux-x86_64/pva2pva loopback.conf

About

PV Access gateway/proxy and EPICS Process Database integration

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages