EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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  <20042005  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: Ralph Lange <[email protected]>
To: "Mark Rivers" <[email protected]>
Cc: "Russell Redman" <[email protected]>, <[email protected]>, <[email protected]>
Date: Thu, 9 Dec 2004 12:39:52 +0100
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  <20042005  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  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·