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
- Replies:
- Re: Initial value readback from hardware into output records Russell Redman
- References:
- RE: Initial value readback from hardware into output records Mark Rivers
- Navigate by Date:
- Prev:
EPICS problem Mark Rivers
- Next:
Re: EPICS problem Andrew Johnson
- 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
- Navigate by Thread:
- Prev:
RE: Initial value readback from hardware into output records Mark Rivers
- Next:
Re: Initial value readback from hardware into output records Russell Redman
- 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
|