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
<2012>
2013
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|