EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Going full PVA?
From: Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Wed, 9 Jun 2021 08:46:20 +0200

Well,


From: Stainer Tom <Tom.Stainer at sckcen.be>
Date: Tuesday 8 June 2021 at 15:53
To: Timo Korhonen <Timo.Korhonen at ess.eu>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: RE: Going full PVA?

 

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….. 


On Tue, 8 Jun 2021 at 17:54, Timo Korhonen via Tech-talk <tech-talk at aps.anl.gov> wrote:

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.

Cheers,
~Ralph

Replies:
RE: Going full PVA? Stainer Tom 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
Navigate by Date:
Prev: Power Meters device support Luchini, Kristi L. via Tech-talk
Next: Quartz crystal microbalance readout SQC-310c device support Arcidiacono, Laura (DLSLtd, RAL, LSCI) 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? Timo Korhonen via Tech-talk
Next: RE: Going full PVA? Stainer Tom 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 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·