Experimental Physics and Industrial Control System
|
Dear Ralph,
Thanks for the response.
For a modular approach... the existing gateway is called IOC.
Create records pointing to the "CA speaking device" and use QSRV to provide them as pvAccess.
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. The database would then handle this mapping between the two protocols.
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. 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?
Has anything like this been published out in the wild so I can take a look how one would go about this perhaps?
Kind regards,
Tom
From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Ralph Lange via Tech-talk
Sent: Wednesday, June 9, 2021 8:46 AM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Going full PVA?
Well,
What I meant with CA <-> PVA translators is if some device is providing data over CA is there a way to make a proxy or gateway to wrap this and convert it to a corresponding PVA signal? As you mentioned below, avoiding vendor specific
EPICS integration is always desired but sometimes unavoidable and I was thinking in these cases what can you do if you want only PVA…..
I guess it would be possible to create such a gateway, although I have not yet seen a case where that would be strictly necessary. I can imagine that there are such
cases, we just have not seen any real blockers yet, or at least none have come to my knowledge.
For a modular approach... the existing gateway is called IOC.
Create records pointing to the "CA speaking device" and use QSRV to provide them as pvAccess.
That has the advantages of being fully compatible with all your other IOCs, moving its EPICS version with all your other IOCs, not using any specific implementations of CA client or PVA server, allowing to put additional logic into the
glue layer (add health monitoring, add logging, combine things, change record names, etc.) without introducing new concepts, languages or implementations and cleanly separating that gateway functionality between different use cases.
At ITER, our practice is to put an IOC in front of any "CA speaking device", just for the sake of conformity and flexibility.
With maybe the exception of the device running an original IOC that we have full control over - OS, EPICS version, database... which I don't expect to happen. High bandwidth low latency applications - think detectors - may become the other
exception.
|
- Replies:
- Re: Going full PVA? Ralph Lange via Tech-talk
- References:
- Going full PVA? Stainer Tom via Tech-talk
- Re: Going full PVA? Timo Korhonen via Tech-talk
- RE: Going full PVA? Stainer Tom via Tech-talk
- Re: Going full PVA? Timo Korhonen via Tech-talk
- Re: Going full PVA? Ralph Lange via Tech-talk
- Navigate by Date:
- Prev:
Quartz crystal microbalance readout SQC-310c device support Arcidiacono, Laura (DLSLtd, RAL, LSCI) via Tech-talk
- Next:
Re: Going full PVA? Ralph Lange via Tech-talk
- 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: Going full PVA? Ralph Lange via Tech-talk
- Next:
Re: Going full PVA? Ralph Lange via Tech-talk
- 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
|
ANJ, 09 Jun 2021 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|