Re: Going full PVA?

[Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>]

On Wed, 9 Jun 2021 at 12:15, Stainer Tom <Tom.Stainer at sckcen.be> wrote:

This is what I was thinking - the IOC is the “translator”. I am assuming in this scenario the IOC would be a soft IOC, as it would merely act as the gateway between CA and PVA, without any direct device support.

Correct.

 

The database would then handle this mapping between the two protocols.

Well, in a way, yes, nah, almost.

The database is the database. CA (client) to database mapping is handled by link support calling into the CA client library. Database to PVA mapping is done inside QSRV.

 

Can I assume that this would work both ways: CA to PVA *and* PVA to CA? I would assume so, but I just want to check I am not missing any nasty pitfalls.

Do you mean PVA to CA when writing through that IOC? That works when the QSRV mapping is done in the right way (which is not always trivial).

Or another IOC that maps a device speaking PVA into a flat CA control system namespace? Don't really know.

One thing I was thinking that would need to be handled would be mapping the structured data of PVA to the flat structure of CA. Is that what QSRV can do, or does it just go CA to PVA way?

That kind of mapping can be done in QSRV, where you can basically create a structure by pointing leaves to record fields in the database.

Again: you're mapping the elements of a PVA structure that QSRV serves up to fields of records in the EPICS database. CA is not involved on this end.

The fact that records can use CA to connect to other IOCs (or other devices running a CA server) is unrelated.

Your clients connect to a normal EPICS IOC using PVA, and you're effectively using CA as a field bus below the IOC, conceptually similar to Modbus, SCPI, EtherCAT, OPC UA, ...

Cheers,
~Ralph