Experimental Physics and
Industrial Control System

[email protected] · Wed, 29 May 2002 09:06:37 +0200

  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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System