Hi Zen,
There are two separate ways to get the value from the driver into an output record.
1) The first way is to have your driver write the value to the parameter library at some point before iocInit. Standard asyn device support always attempts to read the value from the driver in the init_record function at iocInit. If the read returns asynSuccess then the value read is put into the VAL field and UDF is set to 0. The record does not process at iocInit unless the PINI field is YES. This mechanism has existed in asyn since the beginning.
2) The second way is the new feature added in asyn R4-26. It requires that you set the info tag asyn:READBACK to 1. In this case whenever your driver does a callback to device support the output record will process and get the new value. This was not really intended to initialize the value at iocInit, but rather to update the record later if something other than processing that record cause the value in the driver to change.
I just did a test to verify that I believe things are working as they should. asyn comes with a test application called testErrorsApp. That application sets the values of some parameters in the parameter library in the constructor, and updates them periodically in a driver thread.
I just created a new simple database called testErrors1.db for that application. Here it is:
corvette:~/devel/asyn/db>more testErrors1.db
record(longout, "$(P)LongoutInt32")
{
field(DTYP, "asynInt32")
field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))INT32_VALUE")
field(VAL, "0")
}
record(longout, "$(P)LongoutInt32_PINI")
{
field(PINI, "1")
field(DTYP, "asynInt32")
field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))INT32_VALUE")
field(VAL, "0")
}
record(longout, "$(P)LongoutInt32_RB")
{
field(DTYP, "asynInt32")
field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))INT32_VALUE")
field(VAL, "0")
info(asyn:READBACK,"1")
}
record(longout, "$(P)LongoutInt32_RB_PINI")
{
field(PINI, "1")
field(DTYP, "asynInt32")
field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))INT32_VALUE")
field(VAL, "0")
info(asyn:READBACK,"1")
}
It has 4 longout records.
PINI asyn:READBACK present
LongoutInt32 No No
LongoutInt32_PINI Yes No
LongoutInt32_RB No Yes
LongoutInt32_RB_PINI Yes Yes
I then loaded this database into an IOC running the testErrorsApp application. This is the output of dbpr for each of those records with level 10 of output.
epics> dbpr testErrors:LongoutInt32 10
ACKS: NO_ALARM ACKT: YES ADEL: 0 ALST: 1
ASG: ASP: (nil) BKPT: 00 DESC:
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DOL:CONSTANT DPVT: 0x2578c70 DRVH: 0 DRVL: 0
DSET: 0x7f61cceaa900 DTYP: asynInt32 EGU:
EVNT: 0 FLNK:CONSTANT 0 HHSV: NO_ALARM HIGH: 0
HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0
IVOA: Continue normally IVOV: 0 LALM: 1
LCNT: 0 LLSV: NO_ALARM LOLO: 0 LOPR: 0
LOW: 0 LSET: 0x25887f0 LSV: NO_ALARM MDEL: 0
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MLOK: f0 8a 57 02 00 00 00 00 MLST: 1
NAME: testErrors:LongoutInt32 NSEV: NO_ALARM NSTA: NO_ALARM
OMSL: supervisory OUT:INST_IO @asyn(PORT1,0,1)INT32_VALUE PACT: 0
PHAS: 0 PINI: NO PPN: (nil) PPNR: (nil)
PRIO: LOW PROC: 0 PUTF: 0 RDES: 0x2532a30
RPRO: 0 RSET: 0x7f61ccc34180 SCAN: Passive
SDIS:CONSTANT SEVR: INVALID SIML:CONSTANT SIMM: NO
SIMS: NO_ALARM SIOL:CONSTANT SPVT: (nil) STAT: UDF
TIME: <undefined> TPRO: 0 TSE: 0 TSEL:CONSTANT
UDF: 0 VAL: 1
epics> dbpr testErrors:LongoutInt32_PINI 10
ACKS: NO_ALARM ACKT: YES ADEL: 0 ALST: 1
ASG: ASP: (nil) BKPT: 00 DESC:
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DOL:CONSTANT DPVT: 0x2586350 DRVH: 0 DRVL: 0
DSET: 0x7f61cceaa900 DTYP: asynInt32 EGU:
EVNT: 0 FLNK:CONSTANT 0 HHSV: NO_ALARM HIGH: 0
HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0
IVOA: Continue normally IVOV: 0 LALM: 1
LCNT: 0 LLSV: NO_ALARM LOLO: 0 LOPR: 0
LOW: 0 LSET: 0x2588810 LSV: NO_ALARM MDEL: 0
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MLOK: 60 8b 57 02 00 00 00 00 MLST: 1
NAME: testErrors:LongoutInt32_PINI NSEV: NO_ALARM NSTA: NO_ALARM
OMSL: supervisory OUT:INST_IO @asyn(PORT1,0,1)INT32_VALUE PACT: 0
PHAS: 0 PINI: YES PPN: (nil) PPNR: (nil)
PRIO: LOW PROC: 0 PUTF: 0 RDES: 0x2532a30
RPRO: 0 RSET: 0x7f61ccc34180 SCAN: Passive
SDIS:CONSTANT SEVR: NO_ALARM SIML:CONSTANT SIMM: NO
SIMS: NO_ALARM SIOL:CONSTANT SPVT: (nil) STAT: NO_ALARM
TIME: 2015-02-28 08:04:44.076227816 TPRO: 0 TSE: 0
TSEL:CONSTANT UDF: 0 VAL: 1
epics> dbpr testErrors:LongoutInt32_RB 10
ACKS: NO_ALARM ACKT: YES ADEL: 0 ALST: 1
ASG: ASP: (nil) BKPT: 00 DESC:
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DOL:CONSTANT DPVT: 0x2586c80 DRVH: 0 DRVL: 0
DSET: 0x7f61cceaa900 DTYP: asynInt32 EGU:
EVNT: 0 FLNK:CONSTANT 0 HHSV: NO_ALARM HIGH: 0
HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0
IVOA: Continue normally IVOV: 0 LALM: 1
LCNT: 0 LLSV: NO_ALARM LOLO: 0 LOPR: 0
LOW: 0 LSET: 0x2588830 LSV: NO_ALARM MDEL: 0
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MLOK: d0 8b 57 02 00 00 00 00 MLST: 1
NAME: testErrors:LongoutInt32_RB NSEV: NO_ALARM NSTA: NO_ALARM
OMSL: supervisory OUT:INST_IO @asyn(PORT1,0,1)INT32_VALUE PACT: 0
PHAS: 0 PINI: NO PPN: (nil) PPNR: (nil)
PRIO: LOW PROC: 0 PUTF: 0 RDES: 0x2532a30
RPRO: 0 RSET: 0x7f61ccc34180 SCAN: Passive
SDIS:CONSTANT SEVR: NO_ALARM SIML:CONSTANT SIMM: NO
SIMS: NO_ALARM SIOL:CONSTANT SPVT: (nil) STAT: NO_ALARM
TIME: 2015-02-28 08:04:44.173729522 TPRO: 0 TSE: 0
TSEL:CONSTANT UDF: 0 VAL: 1
epics> dbpr testErrors:LongoutInt32_RB_PINI 10
ACKS: NO_ALARM ACKT: YES ADEL: 0 ALST: 1
ASG: ASP: (nil) BKPT: 00 DESC:
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DOL:CONSTANT DPVT: 0x25879b0 DRVH: 0 DRVL: 0
DSET: 0x7f61cceaa900 DTYP: asynInt32 EGU:
EVNT: 0 FLNK:CONSTANT 0 HHSV: NO_ALARM HIGH: 0
HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0
IVOA: Continue normally IVOV: 0 LALM: 1
LCNT: 0 LLSV: NO_ALARM LOLO: 0 LOPR: 0
LOW: 0 LSET: 0x2588850 LSV: NO_ALARM MDEL: 0
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MLOK: 40 8c 57 02 00 00 00 00 MLST: 1
NAME: testErrors:LongoutInt32_RB_PINI NSEV: NO_ALARM NSTA: NO_ALARM
OMSL: supervisory OUT:INST_IO @asyn(PORT1,0,1)INT32_VALUE PACT: 0
PHAS: 0 PINI: YES PPN: (nil) PPNR: (nil)
PRIO: LOW PROC: 0 PUTF: 0 RDES: 0x2532a30
RPRO: 0 RSET: 0x7f61ccc34180 SCAN: Passive
SDIS:CONSTANT SEVR: NO_ALARM SIML:CONSTANT SIMM: NO
SIMS: NO_ALARM SIOL:CONSTANT SPVT: (nil) STAT: NO_ALARM
TIME: 2015-02-28 08:04:44.173736304 TPRO: 0 TSE: 0
TSEL:CONSTANT UDF: 0 VAL: 1
Here is a summary of the UDR, STAT and SEVR fields of each of those records.
UDF STAT SEVR
testErrors:LongoutInt32 0 UDF INVALID
testErrors:LongoutInt32_PINI 0 NO_ALARM NO_ALARM
testErrors:LongoutInt32_RB 0 NO_ALARM NO_ALARM
testErrors:LongoutInt32_RB_PINI 0 NO_ALARM NO_ALARM
This is exactly what I expect.
All records have UDF=0 because the value was successfully read from the driver at in init_record in the device support.
For testErrors:LongoutInt32 the record has never processed because PINI=NO and the asyn:READBACK info tag is not present. It thus has STAT=UDF and SEVR=INVALID. All of the other records have processed, either because they have PINI=YES or because they have the asyn:READBACK tag. Because they have processed STAT and SEVR are both NO_ALARM.
I hope this clarifies things.
Mark
________________________________________
From: Zenon Szalata [[email protected]]
Sent: Friday, February 27, 2015 11:09 PM
To: Mark Rivers; [email protected]
Subject: Re: asyn R4.26
Hi Mark,
I am using asynPortDriver class. The records are initialized after IOC
init and the record in question looks like this:
epics> dbpr CHA:LO:2531-1-2:CWORD,3
ACKS: NO_ALARM ACKT: YES ADEL: 0 ALST: 0
ASG: BKPT: 00 DESC: DISA: 0
DISP: 0 DISS: NO_ALARM DISV: 1 DOL:CONSTANT
DRVH: 0 DRVL: 0 DTYP: asynInt32 EGU:
EVNT: 0 FLNK:CONSTANT 0 HHSV: NO_ALARM HIGH: 0
HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0
IVOA: Continue normally IVOV: 0 LALM: 0
LCNT: 0 LLSV: NO_ALARM LOLO: 0 LOPR: 0
LOW: 0 LSV: NO_ALARM MDEL: 0 MLST: 0
NAME: CHA:LO:2531-1-2:CWORD NSEV: NO_ALARM NSTA: NO_ALARM
OMSL: supervisory OUT:INST_IO @asyn(2531-1,0,1)LO_CWORD PACT: 0
PHAS: 0 PINI: NO PRIO: LOW PROC: 0
PUTF: 0 RPRO: 0 SCAN: Passive SDIS:CONSTANT
SEVR: INVALID SIML:CONSTANT SIMM: NO SIMS: NO_ALARM
SIOL:CONSTANT STAT: UDF TIME: 2015-02-27 15:41:07.126179705
TPRO: 0 TSE: 0 TSEL:CONSTANT UDF: 0
VAL: 0
epics>
I verified that processing the record, it goes into a healthy state. I
suppose there is no harm to process the record, since it will write back
to the hardware which was just read in. The reason I noticed this is
that the EDM byte monitor widget displays the data as uninitialized...
The question still remains, since the record should have been processed
when the value was written to it and yet the record looks like it was
not processed, so what happened?
Thanks Mark,
Zen
On 02/27/15 16:54, Mark Rivers wrote:
> I think STAT and SEVR only get set when the record processes.
>
> When are you doing the callback to device support, before or after iocInit?
>
> If you do the callback after iocInit then the callback will cause the record to process, because it calls scanOnce(). However, if you call it before iocInit it will not call scanOnce() because that will crash the IOC.
>
> Are you using the asynPortDriver C++ base class? If so that takes care of the problem for you because it has a thread that waits for interruptAccept to be true, and then does all of the callbacks to device support.
>
> Mark
>
>
> -----Original Message-----
> From: Zenon Szalata [mailto:[email protected]]
> Sent: Friday, February 27, 2015 5:59 PM
> To: Mark Rivers; [email protected]
> Subject: asyn R4.26
>
> Hi Mark,
> I am beginning to use asyn R4.26, where the new feature that you have
> added to allow initialization of output records, is of interest.
> It works well, except I have noticed one thing.
> In my case I am initializing a longout record from the device driver.
> It gets the value correctly, UDF is set to 0 but STAT has UDF and SEVR
> is INVALID. Do I need to do something else in addition to just push a
> new value to the record? I don't want to process the record, which most
> likely would put the record in a good state.
> Sorry for bugging you and thanks,
> Zen
- Replies:
- Re: asyn R4.26 Zenon Szalata
- References:
- asyn R4.26 Zenon Szalata
- RE: asyn R4.26 Mark Rivers
- Re: asyn R4.26 Zenon Szalata
- Navigate by Date:
- Prev:
Re: asyn R4.26 Zenon Szalata
- Next:
Re: Using the EPICS Build/Make system to build kernel modules for linux Daron Chabot
- 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: asyn R4.26 Zenon Szalata
- Next:
Re: asyn R4.26 Zenon Szalata
- 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
|