Experimental Physics and Industrial Control System
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
- Replies:
- RE: sseq link problem on Linux Shepherd, EL (Emma)
- References:
- sseq link problem on Linux Shepherd, EL (Emma)
- Re: sseq link problem on Linux Tim Mooney
- Navigate by Date:
- Prev:
Re: DBFLAGS in RULES.Db Andrew Johnson
- Next:
RE: Gateway problem .... more info Angelic Ebbers
- 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: sseq link problem on Linux Tim Mooney
- Next:
RE: sseq link problem on Linux Shepherd, EL (Emma)
- 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