Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 20 Feb 2009 11:40:23 -0600

Hi Ralph,

On Friday 20 February 2009 03:51:43 Ralph Lange wrote:
>
> Idea: Why not introduce an additional PINI sweep, and change the PINI
> field to be a three-option choice?
> "NO", "YES", "UP": NO and YES yield the classical behaviour, while "UP"
> puts the record into the second PINI phase, that runs *after* the CA
> client and server are started (I.e., when the IOC is UP).
> Should be compatible, shouldn't break existing stuff, allows CA/CP in
> PINI processing.
> For the Redundant IOC it has the interesting side effect that you can
> select if the record should be processed at boot time, or after the IOC
> has become active.

I like it!

> (If the IOC switches back and forth between active and inactive, would
> UP records be processed whenever it gets active? Do we need to
> distinguish between "Once UP" and "Whenever UP"?)

As well as the redundant IOC we do have the new iocPause and iocRun commands 
which are designed to allow direct control of the running IOC; we probably 
need better mechanisms for the whole pause and run issue anyway.  I am 
therefor inclined to use the PINI state name RUN rather than UP, and also 
have a PAUSE as well to announce that an iocPause command is happening to the 
database before everything gets suspended.  I also think I should add some 
more initHook phases for the whole pause/run cycle — currently the last two 
hooks get announced the first time iocRun gets called, but there are no hooks 
announced in iocPause or any subsequent iocRun calls.

Of course with having multiple PINI phases, what if someone wants processing 
to occur in more than one phase?  Should we add combinations like YES+RUN or 
RUN+PAUSE to the PINI menu item?  I say this looks ugly and probably won't be 
used much; where it is needed developers will just have to have multiple 
records forward-linked to kick off processing.

Bernd also replied:
> We have an additional requirement: The record code of some records need
> to know if it is processed normally, the first time at all or the first
> time after the ioc became active. Up to now we solved this problem by
> introducing a new field in those records and a function, which sets
> these fields, is registered to the redundancy task (RMT). These records
> are in a linked list. When the ioc becomes active the RMT sets the
> fields to a value, so that the record code can see that the record is
> processed first after becoming active.

A record type can always find out if this is a record's first-ever process() 
call by looking at the TIME field; if it's zero (the epoch) it has never 
called recGblGetTimestamp() for this record.  That distinguishes one case.  
The other cases could be distinguished by making the IOC's initialization 
state available, so a record type could do something like
    if (iocInitState() == iocBuilding)
to detect the processing caused by PINI=YES, and
    if (iocInitState() == iocRunning)
for the normal processing state.  It can also change the PINI field itself at 
runtime if it wants to cause re-processing at one of the other events.

Would this solve your requirement?

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System