1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 <2004> 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 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: Initial value readback from hardware into output records |
From: | Russell Redman <[email protected]> |
To: | Ralph Lange <[email protected]>, Mark Rivers <[email protected]> |
Cc: | <[email protected]>, <[email protected]> |
Date: | Thu, 09 Dec 2004 11:20:55 -0800 |
Interesting ...
Looking at the ao record I realized:
While the record support's process() usually checks for the simulation
mode by reading the SIML link and only calls device support in "real
mode", its init_record() only sets SIMM if SIML is a constant and calls
device support anyway.
For a record coming up in simulation mode after a reboot, whatever you
do seems to be wrong:
- If you skip device support's initialization, the record cannot be
switched to real mode later, as the device is not initialized.
- If you do the initialization, you will access hardware, which might
be against the intention for rebooting the record in simulation mode
in the first place.
It looks as if a proper solution will not be available before EPICS is
capable of adding records on-line - then there have to be ways for late
hardware initialization, which can also be used for this case.
For the time being ...
Here's an idea to make a database work more smoothly without the
hardware being present:
In its init routine, the device support should be able to detect if the
hardware is missing. Instead of raising an error and maybe blocking the
record (e.g. done by setting PACT=1) it could internally mark the
hardware as missing and force the record into simulation mode instead.
If your database doesn't use the simulation mode mechanism or has been
set up to come up in simulation mode, everything will be just fine.
What if the record later gets switched to real mode (or gets this from
its SIML location)? Check for the missing hardware flag in the device
support's write routine and raise an error (set the record INVALID). The
overhead for this additional check (done at every processing) should be
tolerable.
Zero-tolerance mode: On production systems (where the hardware should
please really exist) device support should still raise errors and maybe
block the record at boot time. So you might want to add a common global
switch (variable to be set from the startup script) for all your device
supports to enable the fault tolerant procedure (disabled by default).
What do you think? Doesn't really look perfectly elegant, I agree.
Should the case of "missing hardware at boot time" be handled in a more
generic way? (I.e.: what would a future device support interface need to
handle this properly?)
Cheers,
Ralph
>>>>> "Mark" == Mark Rivers <[email protected]> writes:
> Russell,
> The features I was discussing only apply to generic device support for
> drivers that use the new asynDriver interfaces. Since your drivers are
> not based on asyn, and you are not using the asyn generic device
> support, then this will not be a problem for you. Nothing in EPICS base
> has changed in this regard.
> If you begin to use asyn-based drivers, and you don't want the records
> to set the value during init_record you can:
> - Use non-generic device support
> - Write an asyn SIMULATION driver, that looks just like the real driver,
> but does not talk to hardware
> Mark
> -----Original Message-----
> From: Russell Redman [mailto:[email protected]]
> Sent: Tuesday, December 07, 2004 10:44 AM
> To: Mark Rivers; [email protected];
> [email protected]
> Subject: Re: Initial value readback from hardware into output
> records
> I am curious about a closely related issue that I fear will
> arise when we try to upgrade our version of EPICS from 3.13.8 to use
> the newer software. My code runs in both hardware and simulation modes
> to allow the software to be tested without having the hardware attached.
> When the IOC boots, it does not know which mode it is supposed to be in.
> The operator sets HARDWARE/SIMULATION mode flag, then runs an INITIALISE
> action to open communications with hardware or with the simulator, as
> appropriate. Very bad things happen if the EPICS drivers attempt to
> read back values from nonexistent hardware, and I have put a
> considerable effort into the startup code to ensure that I/O records do
> not process on startup.
> So here is my question: How can I PREVENT an output record from
> reading back a value during init_record from hardware that may or may
> not exist?
> Cheers,
> Dr. Russell O. Redman