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
<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: 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
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|