Experimental Physics and
Industrial Control System

"Shepherd, EL (Emma)" <[email protected]> · Sat, 6 Sep 2008 07:19:06 +0100

Hi Tim,

Well that certainly explains things, and as you have thought of a fix
already that's even better!  Thanks :)

Emma

> -----Original Message-----
> From: Tim Mooney [mailto:[email protected]] 
> Sent: 05 September 2008 19:06
> To: Shepherd, EL (Emma)
> Cc: [email protected]
> Subject: Re: sseq link problem on Linux
> 
> 
> 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
> 
> 
<DIV><FONT size="1" color="gray">This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
</FONT></DIV> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System