Experimental Physics and Industrial Control System
Ralph> The effect occurs when the calc/calcout is reading CA input links that
Ralph> are INVALID either because the CA link hasn't connected or it isn't
Ralph> granted read access by the source IOC.
Ralph> ...
Ralph> after a reboot the first processing often occured before all inputs had
Ralph> been connected...
Tim> Yikes! Initializing a database is hard enough without worrying about
Tim> links that haven't connected yet. How about...
Tim> case INITHOOKafterInterruptAccept :
Tim> taskDelay(600); <--<<
Tim> break;
Tim> ....in initHooks() ? Am I right in thinking this would delay processing
Tim> caused by .PINI=="YES", and allow CA links some more time to connect?
Tim> You'd still want to do what you've suggested, of course, to defend
Tim> against links that really are broken. But .PINI is pretty much useless
Tim> if it sometimes causes processing before databases that will eventually
Tim> be sound are ready to go.
Hmmmh.
Well, you are right that it would delay things a bit and _maybe_ allow
some more CA links to connect, but:
o Since there are _many_ reasons why CA input connects could be late,
adding a delay would just shift probabilities a bit. Even in our case
the percentage of switched off power supplies was between 10% and
100% - depending on the local IOC load, the remote IOC load, the
network load, how many other CA clients were connecting etc.
o Actually waiting for the CA inputs to connect could delay the initial
processing infinitely, which contradicts just a bit too much.
o When a record has one or more .CPP input links, PINI is meaningless
anyway. Every connecting CA input link will process the record
once. (Since you always get one update when a monitor connects.)
o With the new behaviour the calc/out record will start performing the
CALC and setting its state to something different from LINK/INVALID
as soon as all inputs are there. This is definitely the desired
behaviour.
Even if one could argue that such a change in behaviour is too big for a
bugfix release and the record support should be changed to show the old
behaviour, I'd rather not take any steps in that direction, since it's
the wrong way.
I guess it is really necessary (and time, maybe) to sweep up the
databases and check that results of calc/out records are handling the
INVALID state correctly. We were relying on a wrong behaviour. _Sigh._
Cheers,
Ralph
- References:
- EPICS Base 3.13.6 Caveat Ralph . Lange
- Re: EPICS Base 3.13.6 Caveat Tim Mooney
- Navigate by Date:
- Prev:
Re: error in caput ("caputting negative numbers") Matthieu Bec
- Next:
EPICS Meeting Spring '02 - Wrap-Up Ralph . Lange
- 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: EPICS Base 3.13.6 Caveat Tim Mooney
- Next:
EPICS Meeting Spring '02 - Wrap-Up Ralph . Lange
- 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