| 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: How to find out PVs preventing SSCAN from running? |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Li, Ji" <liji at bnl.gov> |
| Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Wed, 4 Aug 2021 18:18:24 -0700 |
On 8/4/21 4:42 PM, Li, Ji via Tech-talk wrote: > brought *P1NV *to *PV OK* and enabled the scan. But *$(P)$(R)PID * doesn't get processed when written. How to define the PV as *PP* in such fields in base 7.0.5? The sscanRecord is an exceptional case which does not use the regular EPICS link mechanics. I think that these "link" fields are intended to behave mostly like CA_LINK. The code involved doesn't parse the PV name string provided, so link modifiers can't be used. In detail. There are no DBF_INLINK or DBF_OUTLINK fields defined in sscanRecord.dbd https://github.com/epics-modules/sscan/blob/420274ca2e4331e92119bd0524d0bcd7ffdd9f93/sscanApp/src/sscanRecord.dbd#L1 Instead the recDynLink code is used, which in turn is calling into libca. https://github.com/epics-modules/sscan/blob/420274ca2e4331e92119bd0524d0bcd7ffdd9f93/sscanApp/src/recDynLink.c#L204