Re: Calcout using CA output link sometimes gets INVALID severity

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

----- Original Message -----
> From: "J. Lewis Muir" <jlmuir@imca-cat.org>
> To: "Ralph Lange" <Ralph.Lange@gmx.de>
> Cc: "EPICS Tech Talk" <tech-talk@aps.anl.gov>
> Sent: Friday, October 12, 2012 12:55:27 PM
> Subject: Re: Calcout using CA output link sometimes gets INVALID severity
> On 10/12/12 11:21 AM, Ralph Lange wrote:
> > You might consider moving your functionality into a SNL state
> > machine.
> > By default, the sequencer waits for all CA connections to be up
> > before
> > starting a state set. That seems to be a better fit for your
> > problem.
> 
> Hi, Ralph.
> 
> That's a big pain. That would suggest I should get rid of any
> CA links in my records and only do CA stuff with SNL programs.
> 
> In reality, this calcout thing is a bit contrived; I was just
> creating a small test to show the problem. What I really want
> to do is to use the putNotify functionality that some extension
> records use to wait for all records to finish processing as a
> result of a put. Examples of this are the sseq record
> (WAIT[1-A] fields) in the std module, the scalcout record (WAIT
> field) in the calc module, and the sscan record in the sscan
> module. All of these will have problems if processed before the
> CA links are connected.
> 
> Thanks,
> 
> Lewis

I think EPICS base is not well positioned to address this, because I don't know of an efficient way for base to check a particular record's links before processing it.  I think this is easier to address in record support.

The records you mentioned do maintain information about the states of their links, mostly to alert the user.  The records get fooled in this case, because they assume a CA link to a local PV is connected if the PV exists.  I can fix that, but I don't know what the record should do if processed before all links have connected.  Waiting for links to connect before processing (using timed callbacks to retry) seems reasonable for many use cases, but I can imagine circumstances in which it would be better simply to fail in some obvious way.

This is not just a startup problem.  If you overwrite a link, and then immediately process the record, you can get the same problem.  I think only the sscan record defends itself against that.

This is not the only kind of startup problem that a dbpf shortly after iocInit can expose.  If you have databases that initialize themselves, you probably don't want to write to them until they're ready, and it's not always easy to know when they're ready.

My plan is to make a few record types (sseq, for example) less vulnerable to link-status problems.  I think the additional code required might not be appropriate for all EPICS records.

-- 
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab