Re: sseq link problem on Linux

[Tim Mooney <mooney@aps.anl.gov>]

Shepherd, EL (Emma) wrote:
> Hi all,
>
> I recently encountered an interesting problem when moving an IOC from vxWorks
> to Linux (RedHat).  The database contains a number of sseq records with CP
> input links to pull across some data from another IOC. This happens whenever
> one of the links changes, but also when the IOC boots up for the first time.
> This worked fine on vxWorks, but on Linux the links do not get updated when
> the IOC boots up.  It's not just an occasional failure, it just never worked.
> I changed the sseq records to transforms and it now works fine.  In both
> cases I had PINI=YES.
>
> I'm really interested in inter-IOC link problems in general as we seem to
> suffer from a lot, but this is a nicely reproducible problem that I thought
> someone might be able to shed light on...?

Thanks, Emma, for pointing this out.  The sseq record uses standard EPICS links, 
but it does have a problem with PINI, when any of its links are to PV's in a
different IOC, and there's a looseness about the way it initializes itself
that I'd like to find a good way to fix.

The sseq record needs to know the type (string or numeric) of the PV's it's
linking to, in order to do its job.  (Its job is to be a seq record that
correctly handles strings, as well as numbers).  If the sseq record doesn't
know the data type of a linked PV, it doesn't do anything with the corresponding
link.  If the linked PV is in a different IOC, the sseq record cannot discover
the PV's data type until after EPICS' interruptAccept (because no communication
outside the IOC can happen until after that time).  But PINI processing occurs
before interruptAccept.

So, PINI cannot ever work for links outside the IOC.  (This should be true for
all record types.)  But you have CP links, and they will cause the record to
process again, after interruptAccept, when the sseq record can, at least in
principle, be ready for processing.  I suspect that the record simply hasn't
gotten around to finding out the data type by the time the CP-initiated
processing occurs.  I haven't verified this, but it seems plausible, because the
sseq record gets data types by checking periodically (at 2 Hz) to see if
dbGetLinkDBFtype() returns a valid field type.  If the command to process comes
in the ~.5 second after interruptAccept, and before the sseq record's periodic
link check has succeeded, then the sseq record will not do the right thing.  It
also seems plausible that this timing problem could be systematically different
on different operating systems.

One way to fix the problem would be to have the record postpone link processing
until after the linked PV's data type is known.  The sseq record does all of its
real work in callback routines (as does the seq record), so this would not hold
up other records in the same task.  But if the linked-to PV doesn't exist, then
processing will be postponed indefinitely, so some limit is needed.  I'm not
sure if this is the best way to solve the problem, but it certainly seems like
an improvement over the current code.

--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.