Experimental Physics and
Industrial Control System

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