EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  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 <19941995  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: pvget to an _output_ record
From: [email protected] (Bill Brown)
Date: Mon, 5 Dec 94 13:18:17 PST
> From: [email protected] (Bob Dalesio)
> To: [email protected]
> Subject: Re: pvget to an _output_ record
 
> What hardware are you using? The device support and record support get
> involved here.

Sigh.  OK - here's the scoop

We've got this "historic" control system which we need to interface to
epics; essentially our current view of the world (from epics) is thru
a Bit3 board into a Multibus I chassis.  We have a locally-developed
driver that lets us get and put to the "historic control system" by
writing things into memory reading and writing things into the memory
on the Multibus-I processors.

The cheese starts to bind, so to speak, in that there are other logical
paths which can do essentially the same thing.  There is now way to tell
where the control value is _really_ set on "the other side."

Consider:
    1) Via channel access an analog output gets set to, oh, let's say 5.
    2) At some later time, the value (in the Multibus memory) gets set to 7.
    3) But epics still thinks it's set to 5.  And that's the value that gets
       displayed on the controlling slider (I think).
    4) Worse yet, the archiver records for all posterity that the value is
       still set to 5.
       
So it seemed reasonable to me that a way around this would be to fix device
support so that it would return the real value (by doing a read across the
Bit3 interface) rather than just returning the saved value which may or may
not be correct.

This is a simplified explanation of the problem, but all the important facts
are there.  I hope.  I had hoped that there was something that could tell
device/driver support if the access was a read or a write, but I must have
imagined that there was something in the record struct that did that.

We could use another matching Ai to provide some of the required function,
but it really doesn't do it all.

-bill

Navigate by Date:
Prev: Re: pvget to an _output_ record Bob Dalesio
Next: Re: pvget to an _output_ record Bob Dalesio
Index: <19941995  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: pvget to an _output_ record Bob Dalesio
Next: Re: pvget to an _output_ record Bob Dalesio
Index: <19941995  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 
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 ·