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  <20122013  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Calcout using CA output link sometimes gets INVALID severity
From: Andrew Johnson <[email protected]>
To: "J. Lewis Muir" <[email protected]>
Cc: [email protected]
Date: Fri, 12 Oct 2012 14:07:44 -0500
Hi Lewis,

On 2012-10-12 J. Lewis Muir wrote:
> Anyway, no, I wouldn't want the iocInit to wait until all CA
> links in the database are connected if those links can be to PVs
> that are not local and may not exist.  I didn't know they all
> get connected at start-up.  I thought they got connected as
> needed.  So, for this calcout problem, I would have expected the
> calcout record (or some built-in EPICS Base facility) to
> establish the CA connection if needed before doing the write.
> Or, whatever, the calcout record could command a write using an
> EPICS Base facility, and that facility would ensure the CA link
> is connected before doing the write.

We make life simpler for the record type code by handling all the link 
connection stuff inside the core IOC code; the record isn't normally informed 
if you change a link field at run-time.  If a record tries to get or put data 
through a link that is not currently connected, the link code will put the 
record into a LINK/INVALID alarm state and return an error status.  Some 
record types ignore that error and just carry on processing, others may stop 
processing (it also depends which link gets the error).  Remember that the 
record code cannot block, so it can't wait for a CA search to complete before 
performing I/O through a link.

> > In your case the delay is really a requirement before doing the dbpf
> > because you don't want to process that calcout record until the output
> > link has connected.  Maybe a more robust alternative might be to provide
> > a command which waits for a named link field to have connected, so
> > instead of a delay you'd use something like
> >     dbcaWaitConnected "ioc23:PresetHistoryAdd.OUT"
> > but I don't know how easy it would be to implement that.
> 
> That would be nice--way better than a delay.
> 
> Even better for me would be a dbcaWaitAllLocalConnected that
> would wait for all local PVs to be connected.  I'd put that
> after iocInit in every single one of my IOCs.  I can't even
> think of a case where I wouldn't do that.  Is there a case where
> one wouldn't want to do that?  Of course, if there is no case
> where one wouldn't want to do that, then it starts to seem like
> it should be in iocInit.

That depends how well the "local PV detection" works, and that's the real 
problem with your request, we don't know in advance which CA links are going 
to connect, even if they do specify the name of a record which is found in 
this IOC.  In 3.15 a PV name can specify a server-side filter after the 
<record or alias name>.<field name> parts, but if the filter specification 
part has an error in it the channel will never connect even if the record and 
field part is correct.  Even in 3.14.12 if you append a '$' to a field name 
which is not a DBF_STRING or a DBF_*LINK it won't connect.

I don't think we could safely look at a PV name in a CA link and be sure 
whether it will successfully connect over CA or not.  You wouldn't want any 
false positive answers to the "is this a local PV" test because your command 
would wait forever if it hit one.

I could probably implement a command in 3.15 that takes a (list of) link field 
name(s) and waits for it/them to all be connected, but that's probably the 
best we could manage.  If there's a typo in a link PV name though it would 
never return.

epicsThreadSleep() is much less effort though, and works today...

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

References:
Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir
Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
Re: Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir

Navigate by Date:
Prev: Re: Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir
Next: Re: Calcout using CA output link sometimes gets INVALID severity Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Calcout using CA output link sometimes gets INVALID severity J. Lewis Muir
Next: Immediately reprocess a record [SEC=UNCLASSIFIED] LYNCH, Damien
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·