2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: SIML type CA and PINI=YES issue |
From: | "Kasemir, Kay" <[email protected]> |
To: | EPICS Core Talk <[email protected]> |
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: [email protected] <[email protected]> on behalf of Ralph Lange <[email protected]>
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
|