I love these little database 'snippets'. But what happens when the IOC is rebooted?
It seems that FileNumber (with PINI=YES) could process first after iocInit(), causing FileNumber_write to process and send a "1" to the hardware before FileNumber_RBV tries to read back from the hardware and set the actual value into FileNumber. Even using autosave would keep things 'bumpless' only in the case where no external change was made to the hardware while the IOC down or being rebooted.
It seems like additional logic is required to disable FileNumber until at least FileNumber_RBV has processed once. Or else declare PINI=NO on FileNumber.
On 11 Feb 2010, at 05:51 , 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
>
>
> ________________________________
>
> From: [email protected] on behalf of Hinko Kocevar
> Sent: Thu 2/11/2010 6:27 AM
> To: [email protected]
> Subject: MBBO update
>
>
>
> Hi,
>
> I'm using mbbo record type that provides 5 values/strings. When mbbo
> record is controlled from EDM panel using Radio Box I can set the record
> value to desired state.
>
> If the state changes in the underlying software my mbbo record does not
> update the value - eg. Radio Box button that was last pressed remains
> selected in the EDM panel, while actual state changed.
>
> How can this be done?
>
> Providing mbbi record with same PORT and ADDR as mbbo, I can see that
> the state in mbbi record updates as soon as the underlying software
> changes the value. But this does not update the mbbo record, though..
>
>
> Here is the mbbo record:
>
> record(mbbo, "$(DEVICE)SWITCH") {
> field(DTYP, "asynInt32")
> field(OUT, "@asyn($(PORT), 0, 1.0)")
> field(ZRVL, "0")
> field(ONVL, "1")
> field(TWVL, "2")
> field(THVL, "3")
> field(FRVL, "4")
> field(ZRST, "MANUAL")
> field(ONST, "AUTO")
> field(TWST, "AVERAGING")
> field(THST, "COMPENSATING")
> field(FRST, "AVE & COMP")
> field(PINI, "YES")
> }
>
>
>
> Best regards,
> Hinko
>
> --
> Hinko Kocevar
> Technical support software engineer
> Instrumentation Technologies
> Velika pot 22, SI-5250 Solkan - Slovenia
> T:+386 5 3352600, F:+386 5 3352601
> mailto: [email protected]
>
> http://www.i-tech.si <http://www.i-tech.si/> - When your users demand stability
>
> The information transmitted is intended solely for the addressee and may
> contain confidential and/or privileged information. Any review, retention,
> disclosure or other use by persons other than the intended recipient is
> prohibited. If you received this in error, please notify the sender and
> delete all copies.
>
>
>
>
- Replies:
- RE: MBBO update Mark Rivers
- References:
- MBBO update Hinko Kocevar
- RE: MBBO update Mark Rivers
- Navigate by Date:
- Prev:
Re: MBBO update Ralph Lange
- Next:
RE: MBBO update Mark Rivers
- 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 Hinko Kocevar
- Next:
RE: MBBO update Mark Rivers
- 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
|