Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Fri, 05 Sep 2008 13:05:53 -0500

Tim Mooney wrote:

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, 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.
Actually, the fix is simpler than that. With the following changes, the
sseq record

does the right thing the first time it processes because of a CP input link:
In the function "processCallback(CALLBACK *pCallback)", add the lines
   if (plinkGroup->dol_field_type == DBF_unknown)
       plinkGroup->dol_field_type = dbGetLinkDBFtype(&plinkGroup->dol);
immediately before the line
 switch (plinkGroup->dol_field_type) {
and add the lines
   if (plinkGroup->lnk_field_type == DBF_unknown)
       plinkGroup->lnk_field_type = dbGetLinkDBFtype(&plinkGroup->lnk);
immediately before the line
 switch (plinkGroup->lnk_field_type) {

I don't know why I didn't just write it this way in the first place.
--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group (www.aps.anl.gov/aod/bcda)
Advanced Photon Source, Argonne National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System