EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20202021  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  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: detecting remote PV disconnect (asyn)
From: Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
To: Hinko Kocevar <Hinko.Kocevar at ess.eu>, Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk <tech-talk at aps.anl.gov>
Date: Mon, 23 Mar 2020 10:39:56 -0700
On 3/23/20 9:55 AM, Hinko Kocevar via Tech-talk wrote:
> Hi Mark,
> 
>> - Both $(P)$(R)TimestampIn and $(P)$(R)Timestamp are in the same IOC.  That is not the IOC you are killing.
> 
> These live in the DAQ IOC, not EVR IOC (which I'm killing).
> 
> 
>> - The TSEL link is talking to another IOC (the EVR IOC), PV="LAB-
> EVR-000:EvtECnt-I.TIME CP MS"
> 
> Yes LAB-
> EVR-000:EvtECnt-I.TIME is on EVR IOC. Using MS flag there makes me think that alarm severity would be propagated to the record holding TSEL (I have never done this before so I might be wrong on this assumption).

Normally yes, but .TIME is handled as a special case, so I wouldn't be surprised
if this didn't work.  I'd recommend using an additional longin record to subscript
to the value of the event Cnt-I PV.  Then forward link from this to your records.


>> - Is the OUT link is talking to a local driver?  What does this driver do?  "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
> 
> Yes, OUT is local to an asyn driver (DAQ driver). Asyn code for DAQ driver takes the value obtained from EVR IOC PV and writes it to the firmware on top of which the DAQ IOC sits.
> 
>> Does TimeStampIn record ever go into alarm state when the EVR IOC shuts down?  It may take the time that the OS requires to detect that a socket is closed, which can be many minutes.
> 
> I do not think so. I've been looking at the "dbpr TimeStampIn 4" and none of the fields change value when comparing alive EVR PV vs dead EVR PV.
> 
>> It seems to me that the record that should first detect the problem is not using asyn, it is the TimestampIn record.  So this is really not an asyn question, it is the behavior of EPICS base in general for CP links.
> 
> True. The first record is no using asyn.
> Is there a way to check that the EVR PV disappeared?
> 
> 
> //hinko
> 
> Mark
> 
> ________________________________
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hinko Kocevar via Tech-talk <tech-talk at aps.anl.gov>
> Sent: Monday, March 23, 2020 11:11 AM
> To: tech-talk at aps.anl.gov
> Subject: detecting remote PV disconnect (asyn)
> 
> Hi,
> 
> I have an EVR PV that delivers timestamp to my asyn based DAQ IOC. I want to know if and when that PV is inaccessible - i.e. EVR IOC not running / died.
> 
> I have this DB construct:
> 
> # get timestamp from EVR event PV
> # i.e. set TSEL: LAB-EVR-004:EvtECnt-I.TIME CP MS
> record(stringin, "$(P)$(R)TimestampIn") {
>     field(DTYP, "Soft Timestamp")
>     # use dummy placeholder PV, change EVR prefix to a desired EVR IOC
>     field(TSEL, "LAB-EVR-000:EvtECnt-I.TIME CP MS")
>     field(INP,  "@%s.%f")
>     field(FLNK, "$(P)$(R)Timestamp.PROC PP MS")
>     info(autosaveFields, "TSEL")
> }
> 
> # holds TS value in 'sec.nsec' format
> record(stringout, "$(P)$(R)Timestamp")
> {
>     field(DOL,  "$(P)$(R)TimestampIn")
>     field(OMSL, "closed_loop")
>     field(DTYP, "asynOctetWrite")
>     field(OUT,  "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
> }
> 
> 
> Works as expected. The $(P)$(R)Timestamp is refreshed upon each update of the LAB-EVR-000:EvtECnt-I PV, feeding the value to the asyn based IOC code.
> 
> Upon killing the EVR IOC the $(P)$(R)TimestampIn and $(P)$(R)Timestamp show no apparent state change that the LAB-EVR-000:EvtECnt-I went away. At least looking that the "dbpr ... 4" output for the above mentioned PVs.
> 
> I was expecting the alarm fields to be set to something like "not connected". Is there a way, in asyn based IOC, to detect this situation?
> 
> Thanks,
> Hinko
> 


Replies:
Re: detecting remote PV disconnect (asyn) Hinko Kocevar via Tech-talk
References:
detecting remote PV disconnect (asyn) Hinko Kocevar via Tech-talk
Re: detecting remote PV disconnect (asyn) Mark Rivers via Tech-talk
Re: detecting remote PV disconnect (asyn) Hinko Kocevar via Tech-talk

Navigate by Date:
Prev: Re: monitors on array variables Siddons, David via Tech-talk
Next: Re: detecting remote PV disconnect (asyn) Mark Rivers 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  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: detecting remote PV disconnect (asyn) Hinko Kocevar via Tech-talk
Next: Re: detecting remote PV disconnect (asyn) Hinko Kocevar 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  <20202021  2022  2023  2024 
ANJ, 24 Mar 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·