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 <2025> | 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 <2025> |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: archiver appliance and CA -> PVA |
From: | Sky Brewer via Tech-talk <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 30 Jan 2025 15:10:27 +0000 |
Hi all, Furthermore, even explicity archiving them with pva:// they still won't connect. Apart from reverting back to CA, what can I do so that they connect to the AA with PVA? Resubmitting should work, but the PVs need to be removed from the archiver first, via delete for example. We currently don’t have a feature to migrate from CA to PVA or vice versa. Sounds like a good idea though, made
an issue: https://github.com/archiver-appliance/epicsarchiverap/issues/325 For fun, I tried simply changing this key for a couple of scalar double PVs. I was a little concerned that these might show up as Type Change events, which AA does not handle. However, in this case it did not. So all is well. This I think should work, but probably you want to do a restart of the archiver after rather than doing this live. An alternative is: Pause the pv Use the /getPVTypeInfo endpoint to get the type info Edit the json output to have pvAccess set to True Use the /putPVTypeInfo endpoint
https://epicsarchiver.readthedocs.io/en/latest/developer/mgmt_scriptables.html
to update the pvTypeInfo. Resume the PV I don’t particularly want to encourage this , as it isn’t much different to manually changing in the db. And just as risky. Resubmission I think is the safest method. Hope that helps Sky |