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: PVXS IOC Philosophy |
From: | "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Dave Bracey <dbracey at fnal.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Wed, 20 Mar 2024 16:42:54 +0000 |
I’d say the prevalent scenarios would still be IOCs with records, and PVAccess is then used just like Channel Access. That’s why we have normative types which mostly mirror the DBR_.. types, and clients like CS-Studio that can fairly transparently
switch between the two protocols. With PVAccess you do now have the option to use new types. It allows you to transfer site-specific data over the same protocol, but you can’t expect generic widgets to fully understand your data. That mostly means you need to create both
the server and the client, which you can do in python etc. The new ‘group’ feature does allow you to create custom types by on combining data from records, but for the client side you’re then again on the hook to create for example a python script to understand that custom data. So bottom line the goal here should not be that every piece of information now needs to be placed in a newly developed data type with its own custom server and client. On the contrary, the existing record types, the normative types to read/write
them, and generic clients like display managers are meant to fill most of your needs, as was the case with EPICS for the last 30 years. |