Experimental Physics and Industrial Control System
|
Hello Hinko,
Some device supports, which are connecting to hardware capable of
running in a multi-master setup, achieve this by processing the passive
output record when a value update comes in from the hardware:
In the interrupt handler, device support sets a flag in its private
structure and issues a scan request for the record, i.e. it basically
fakes the second part of an asynchronous operation. When the record is
being processed, device support checks the flag and updates the record
with the value from the hardware (instead of writing from the record to
the hardware).
Works flawlessly, does not need additional records, but of course
doesn't solve the classic race condition when two masters (IOC and the
other guy) try to write at the same time.
Cheers,
Ralph
On Thu 11 Feb 2010 8:51:55 Mark Rivers wrote:
Hi Hinko,
This is a classic problem of having more than one mechanism for driving an output, and keeping the output PV up-to-date.
Here is a database fragment that handles this logic (thanks to Tim Mooney for this).
FileNumber is the output record, the equivalent of the mbbo record in your case. Note that it uses soft device support, it does not talk directly to the hardware. FileNumber_RBV is the input record, the equivalent of the mbbi record in your case. In my case it it I/O Intr scanned, i.e. it processes when the hardware driver does a callback to device support, but it could also be periodically scanned. There are 2 additional records required. FileNumber_write is the record that actually talks to the hardware. FileNumber_Sync is a record that copies the readback value from FileNumber_RBV to FileNumber, but WITHOUT causing the value to be written to the hardware. It works because the FileNumber_write record has scan disabled if the FileNumber_sync record is processing (PACT=1). With this logic FileNumber will correctly reflect the actual state of the hardware, and it can also be written to change the hardware.
record(longout, "$(P)$(R)FileNumber")
{
field(PINI, "YES")
field(OUT, "$(P)$(R)FileNumber_write PP")
field(VAL, "1")
}
record(longout, "$(P)$(R)FileNumber_write")
{
field(SDIS, "$(P)$(R)FileNumber_Sync.PACT")
field(DISV, "1")
field(DTYP, "asynInt32")
field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))FILE_NUMBER")
}
record(longin, "$(P)$(R)FileNumber_RBV")
{
field(DTYP, "asynInt32")
field(INP, "@asyn($(PORT),$(ADDR),$(TIMEOUT))FILE_NUMBER")
field(SCAN, "I/O Intr")
field(FLNK, "$(P)$(R)FileNumber_Sync")
}
record(longout, "$(P)$(R)FileNumber_Sync")
{
field(DOL, "$(P)$(R)FileNumber_RBV NPP")
field(OMSL, "closed_loop")
field(OUT, "$(P)$(R)FileNumber PP")
}
Mark
- Replies:
- Re: MBBO update Hinko Kocevar
- Re: MBBO update Hinko Kocevar
- References:
- MBBO update Hinko Kocevar
- RE: MBBO update Mark Rivers
- Navigate by Date:
- Prev:
EPICS_CA_MAX_ARRAY_BYTES Matthieu Bec
- Next:
Re: MBBO update Stephen Lewis
- 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: MBBO update Mark Rivers
- Next:
Re: MBBO update Hinko Kocevar
- 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
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|