Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: SIML type CA and PINI=YES issue
From: Ralph Lange <ralph.lange@gmx.de>
To: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Wed, 29 Nov 2017 19:28:55 +0100
This is getting more complicated.
After some failing workarounds and more discussions, we arrived at the more general question.

Currently (and in the past), when during process() reading the simulation mode through the SIML link fails, the record goes into LINK/INVALID, without calling the device support and without using the IVOV/IVOA configuration (for output records).
We do not think this is really appropriate. If just its simulation switch becomes unavailable, why should the record become INVALID? Turning everything white/magenta, not writing to the hardware, etc.? If you keep your simulation logic on a separate (soft) IOC, shutting it down will effectively brick your running production IOC. There's not enough reason for such drastic measures.

I propose changing the behavior towards ignoring the return value from the SIML check in process().
If there was a way to generate out-of-band events for records, this would be a a perfect use case. I think that in the current context we should just ignore it.

This is a change in behavior, but we are at a major version jump, and I wouldn't expect an application to rely on records being LINK/INVALID for a disappearing SIML.

What do you think?
~Ralph


On Wed, Nov 29, 2017 at 3:55 PM, Ralph Lange <ralph.lange@gmx.de> wrote:
Hi,

I found the reason for records with SIML of type CA and PINI=YES being LINK/INVALID after a reboot:

PINI=YES processing happens before the CA server is initialized. The SIML link does not get resolved during PINI phase process() and the record gets into LINK/INVALID.

Using SIML links of type CA is generally useful, as using DB links pulls all records pointing to the same sim switch record into the same lockset, and - depending on your application - that may be many. (Thousands in our case.)

A legal way out is setting PINI=RUNNING which processes the record after the CA server is up.
In our case this does not work, as we need the PINI processing (records write into the driver's buffer) to be done before interruptAccept (driver starts writing to the device).

What we plan to do is processing all records from the driver after the driver has written to the device, to reset the LINK/INVALID state. Seems like an ugly workaround, though.

Any better ideas? Check for CA being up (or interruptAccept?) when reading a CA type SIML as part of process()?

Thanks,
~Ralph



Replies:
Re: SIML type CA and PINI=YES issue Kasemir, Kay
References:
SIML type CA and PINI=YES issue Ralph Lange

Navigate by Date:
Prev: Re: git problem Andrew Johnson
Next: Re: SIML type CA and PINI=YES issue Kasemir, Kay
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: SIML type CA and PINI=YES issue Ralph Lange
Next: Re: SIML type CA and PINI=YES issue Kasemir, Kay
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 29 Nov 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·