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: "Kasemir, Kay" <kasemirk@ornl.gov>
To: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Wed, 29 Nov 2017 18:36:05 +0000

Agree that if SIML cannot be read, just continuing to operate as if there was no SIML link is appropriate.

Stopping the normal operation of the record is clearly too drastic.


Only problem:

Assume you do want to simulate, and you mis-type the SIML link text.

Will you still get some error indication that tells you about the problem?

The LINK/INVALID and especially stopping the normal operation was too severe,

but at least you knew that you need to look for a broken link.



From: core-talk-bounces@aps.anl.gov <core-talk-bounces@aps.anl.gov> on behalf of Ralph Lange <ralph.lange@gmx.de>
Sent: Wednesday, November 29, 2017 1:28 PM
To: EPICS Core Talk
Subject: Re: SIML type CA and PINI=YES issue
 
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


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

Navigate by Date:
Prev: Re: SIML type CA and PINI=YES issue Ralph Lange
Next: Re: git problem Dirk Zimoch
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: SIML type CA and PINI=YES issue Ralph Lange
Next: Re: SIML type CA and PINI=YES issue Ralph Lange
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 ·