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: Record processing knowledge of dbAccess context
From: "Thompson, David H." <[email protected]>
To: Marty Kraimer <[email protected]>, "Peregrine M. McGehee" <[email protected]>, [email protected]
Cc: [email protected]
Date: Fri, 09 Apr 2004 11:03:59 -0400
I have some bi-directional PVS working in the shared memory stuff and we need them in the SNS machine protection system and several other places.   

I think most possible ways to one of the standard pv type to be bi-directional have at least two things in common, 1-you will have supplied your own device support, and 2-you will have provided a thread to process the record in the direction opposite from which it was designed.   The flag can be in the dpvt structure or in thread local storage.

So if you have an output record that must respond to changes you have your own scanPeriodic() in the driver. In this case you put the context some where in the dpvt structure and then set the context and the value before processing the record in the driver's scan task.  The record's SCAN field is set to "passive".

I found two different ways to implement this method.  Given that the device support's dpvt structure has an read-write context flag you can either:

Implement an extra function to do input in the device's dset and you can call that in the extra scan task.  The extra function would then do the input and set the context flag.  That way the flag stays inside the driver.  The return value of this function could be used to decide whether to "process" the record and thus set the monitors.  All of this happens inside of a scan lock.  When the device's output function is called by the record's process function and the context flag is set to input it just clears the flag and returns without doing any I/O.  This does not involve any dbputs.  I extnded the dset to 11 functions and put the input function in the 11th slot so it could always be in the same place.



-OR-

You have the input scan task do the IO to read the current value from the hardware and use dput to set it.  In this case the scan task would have to know more about the hardware.  If the flag is in TLS the device's output rotine can look at the flag to see if it needs to really do the output operation otherwise the flag in dpvt would have to be set in the same way as the above.

The first method seems more elagant to me but is more likely to be broken by 3.15.  It is also what I hope a later version of base would look like.  The second method is probably where you are.  VxWorks, windows, and linux all support TLS.






-----Original Message-----
From: Marty Kraimer [mailto:[email protected]]
Sent: Fri 4/9/2004 8:16 AM
To: Peregrine M. McGehee; [email protected]
Cc: [email protected]
Subject: Re: Record processing knowledge of dbAccess context
 


Peregrine M. McGehee wrote:

> In which case a possible solution for a bidirectional record
> (without custom record types but with custom device support) is:
>
> record A : input record with custom dev sup, scan PASSIVE
> record B : periodically scanned record, with FLNK to A
>
> within A's read_xxx device support function:
>      if PUTF true then
>     grab VAL and write to hardware
>      else
>     read from hardware and write to VAL
>
> This writes on demand from the CA client and reads periodically.


Yesterday when Peregrine, with help from Fritz Bartlett, suggested this 
I sounded negative.

Thinking about it going home I started thing it was a nice idea. I am 
always suprised when someone discovers a new use for something created 
for a completely different reason. Since PUTF was created only to 
support reprocessing a record if PACT is true when a dbPutField occurs, 
this is what happened.

It is also a little scarry because it means that the original feature 
must not be changed in such a way that it breaks the new usage. This is 
prbably why my initial reaction was negative.

Marty Kraimer









Navigate by Date:
Prev: Re: Record processing knowledge of dbAccess context Peregrine McGehee
Next: Re: Record processing knowledge of dbAccess context Marty Kraimer
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: Record processing knowledge of dbAccess context J. Frederick Bartlett
Next: Problem starting StripTool JaSeong Ju
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 ·