Hi Ignacio,
Out of curiosity, have you measured that overhead? For my own purposes, they'd have to be very significant to make the effort of writing code worth it...
Using records means you don't have to write any code, so any API changes won't affect you, and the probability of adding bugs is smaller. And you already have records for those
devices, no? Furthermore, implementing custom logic for PVAccess would mean that any CA client won't be able to access them.
Cheers,
Érico
Obter o Outlook para Android
De: Tech-talk <tech-talk-bounces at aps.anl.gov> em nome de Ignacio Arriagada via Tech-talk <tech-talk at aps.anl.gov>
Enviado: segunda-feira, outubro 16, 2023 7:54:53 PM
Para: Veseli, Sinisa <sveseli at anl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Assunto: Re: DBRecord <-> PVRecord data exchange
Thank you Michael, Sinisa and Tech-talk in general.
I'm trying to bridge very old EPICS IOC based systems (with very old HW) with newer systems, so I need to marry old EPICS3 stuff with newer EPICS7 stuff.
I've been able to use pvgroups successfully, but it's kinda clunky in that I need a whole lot of Records to assemble the group, with the overheads that that signifies. It works, so it's currently our best implementation, but I'm trying to learn by implementing
something at a lower level using PVdata and databases.
Sinisa, the pvapy implementation has been very useful in this new exploration. It's great.
I started with PVAccess as there seem to be more examples, however I will be moving to PVXS soon, so you will probably hear more from me then.
Thank you all again for your help,
Regards,
Ignacio
Hi,
pvaClient is just a client library for interacting with PVA server over pvaccess.
I hope this helps,
Sinisa
--
Siniša Veseli
Scientific Software Engineering & Data Management
Advanced Photon Source
Argonne National Laboratory
(630)252-9182
Hello Joao,
Thank you so much for your reply!
I think I understand. What I need is closer to [4], but this leads me to the following questions.
- Is using the pvaClient lib the only way to interact with a PVRecord? If I want to trigger processing on a PVRecord from a thread running on my IOC, would something like a putGet() on the PVStructure of said record be THE way to trigger it?
- For PVRecords, is there something like SCAN=EVENT? For DBRecords, I would call postEvent(eventNameToHandle("rec_trgr")) to process a particular record or set of records from within a thread or a callback. Is there something like it for PVRecords?
Thanks again for your help and patience.
Best regards,
Ignacio
Hello Ignacio,
It depends on exactly what you want to achieve. If you want to create a Normative Types PV from your regular EPICS database, you might want to use the PV groups [1].
You also can do a lot by using PVA links [2] in your database records.
In the example below you would read from PVA to a longin record:
record(longin, "$(P)$(R)DBRInput") {
field(DESC, "Copy of PVAInput")
field(INP, {pva:{pv:"$(P)$(R)PVAInput",proc:true}})
}
You can also do the other way around and write to a Normative Types PV:
record(longout, "$(P)$(R)DBROut") {
field(DESC, "write using PVA")
field(OUT, {pva:{pv:" $(P)$(R)PVAOut"}})
}
PVA links are available in the pva2pva library that is part of EPICS Base already, and soon will be also in PVXS (QSRV2).
But if you need at a more "complex" integration, I would definitively go for PVXS inside you IOC [3]. You can use the aSub record to read from your regular DBR PVs (records) and from there you can use the SharedPV class from PVXS to do whatever you want. Bruno
Martins has a very nice example [4]. If your "old" IOC runs EPICS Base 7+ and QSRV is enabled, it is already producing Normative Types PVs that could be accessed by a PVXS client context via read (get) and subscription (monitor) operations inside the same
IOC.
[1] -
https://epics-base.github.io/pva2pva/qsrv_page.html#qsrv_group_def
[2] -
https://epics-base.github.io/pva2pva/qsrv_page.html#qsrv_link
[3] -
https://indico.fnal.gov/event/58280/contributions/264559/
[4] -
https://github.com/brunoseivam/tabulator/blob/main/stackerApp/src/stackerSup.cpp
Kind regards,
João Paulo Martins
European Spallation Source ERIC
Hello Tech-Talk!
I'm trying to integrate PVAccess (or PVXS) capabilities into an old IOC.
- What would be the best way to exchange data between the old DBRecords and the new PVRecords with custom data structures, within the same IOC?
- Do I need to set up a pvClient within the same ioc?
- Does the exchange need to be done via PVAccess connections or is there an internal way of doing it?
I've been reading
Marty Kraimer EPICSV4 developers guide and associated git examples. I'm also consulting Michael Davidsaver's PVXS documentation but it is not clear to me yet how to accomplish this. Are there other resources or examples that I could access regarding this
topic?
Thank you all in advance,
Regards,
Ignacio
Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta
ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying
to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.
- References:
- DBRecord <-> PVRecord data exchange Ignacio Arriagada via Tech-talk
- Re: DBRecord <-> PVRecord data exchange Joao Paulo Martins via Tech-talk
- Re: DBRecord <-> PVRecord data exchange Ignacio Arriagada via Tech-talk
- Re: DBRecord <-> PVRecord data exchange Veseli, Sinisa via Tech-talk
- Re: DBRecord <-> PVRecord data exchange Ignacio Arriagada via Tech-talk
- Navigate by Date:
- Prev:
MBBO IVOA has different behavior in IOC shell and Unix terminal Marco A. Barra Montevechi Filho via Tech-talk
- Next:
Re: PVA connection problem Jörn Dreyer 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: DBRecord <-> PVRecord data exchange Ignacio Arriagada via Tech-talk
- Next:
Re: DBRecord <-> PVRecord data exchange Michael Davidsaver 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
|