Experimental Physics and Industrial Control System
Dear Mark,
On 05/11/10 18:53, Mark Rivers wrote:
> Hi Hinko,
>
> asyn support for I/O Intr scanned records requires that you NOT specify
> PINI=YES for those records. The problem is with the ring buffer used
> for callbacks. But as I recall the symptom of that problem is not what
> you are seeing. The symptom is that the value will be 1 reading
> "stale", not that it won't update at all. But that is for the most
> recent version of asyn. What version are you using?
Hmm, I was not aware of this PINI field limitation.
Asyn version is 4-9.
>
> Try removing PINI=YES from the mbbi record (it is fine in mbbo record).
Tried it.
It does not help - I think that high CPU load is the main issue here, as
stated in previous post.
>
> The problem that you can then run into is that the initial value of the
> record may not match the hardware, unless your driver ensures that it
> does one initial callback. The trick there is that you must not do that
> callback until EPICS is ready for it, i.e. after interruptAccept=1. My
> asynPortDriver code takes care of all of this. It caches any callbacks
> from the driver until interruptAccept=1, and then does all pending
> callbacks to device support then.
The main reason for adding PINI field to most of my records is to make
first time record initialization at startup.
I'm not that familiar with EPICS internals - is the interruptAccept some
global variable I can rely on? Can you maybe post some code on how your
driver handles the interrupt?
Thanks,
Hinko
>
> Mark
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Hinko Kocevar
> Sent: Tuesday, May 11, 2010 11:40 AM
> To: [email protected]
> Subject: Re: No monitor refresh
>
> Hi all,
>
> On 05/11/10 18:30, Hinko Kocevar wrote:
>> Hello Mark,
>>
>> On 05/11/10 18:17, Mark Rivers wrote:
>>>>> As Ralph pointed out, you have set SCAN=I/O Intr. For this to work
>>> your
>>>>> asyn port driver (called ENV in your case) must do callbacks to
>>> device
>>>>> support when it receives a new value. Does this driver do so?
>>>
>>>> Yes it does. I can confirm that the value indeed does change in
> lower
>>>> levels. Even caput response is showing new value. Also when
>>> (re)starting
>>>> the camonitor the first value shown is always prompt and correct!
>>>
>>> Those observations do not prove that your driver is doing calbacks
> when
>>> a value changes. They do prove that your driver is getting new
> values
>>> OK, and that an asynInt32 read from the driver is working. Your mbbi
>>> record has PINI=YES, so it will do a real read from the driver once
> at
>>> iocInit. But unless your driver does callbacks to device support,
> then
>>> it will not get any future values if SCAN=I/O Intr. The proof will
> be
>>> if SCAN="1 second" works, but "SCAN=I/O Intr" does not work.
>>>
>>
>> Interesting PINI stuff - the PINI field was added on top of the
> existing
>> record definition by me, and I seem to be having trouble since. I
> can't
>> really put my finger on it where the issue lies!
>>
>> OK. So changing the SCAN field should prove this. Will try!
>
> I've changed the SCAN field to '1 second' and now I get every value
> change on camonitor!
>
> Is this related to PINI field? I can recall that before adding PINI
> fields to my records, I did not experience this behavior with the I/O
> Intr scanned records.
>
>
> Here is my interrupt code for I/O Intr records, should modify anything
> to make it work with the I/O Intr?:
>
>
> static void env_interrupt_int32_rec (void *drvPvt) {
> ELLLIST *pclientList;
> interruptNode *pnode;
> asynInt32Interrupt *pinterrupt;
> int command;
> drvLiberaPvt_t *pPvt;
>
> pPvt = (drvLiberaPvt_t *)drvPvt;
> assert(pPvt != NULL);
> DEBUG ("portName %s portmode %d\n", pPvt->portName,
> pPvt->conn_param.mode);
>
> pasynManager->interruptStart(pPvt->int32Pvt, &pclientList);
> pnode = (interruptNode *)ellFirst(pclientList);
>
> while (pnode) {
> pinterrupt = (asynInt32Interrupt*)pnode->drvPvt;
> pasynManager->getAddr(pinterrupt->pasynUser, &command);
>
> /* Send individual interrupt to records holding
> defined value */
> switch (command) {
> ...
>
> case 725: {
> pinterrupt->callback
> (pinterrupt->userPvt, pinterrupt->pasynUser,
> pPvt->env_data->agc);
> break;
> }
>
> ...
>
> default: {
> DEBUG ("interrupt for command %d
> UNSUPPORTED!\n", command);
> break;
> }
> }
> pnode = (interruptNode *)ellNext(&pnode->node);
> }
> pasynManager->interruptEnd(pPvt->int32Pvt);
> }
>
>
> The env_interrupt_int32_rec() routine is called when an event from the
> lower level is received - event signal the value change.
>
> Best regards,
> Hinko
>
>>
>>> Note that if you wrote your asyn driver to inherit from
> asynPortDriver,
>>> then getting callbacks to work would consist of setting a single bit
> in
>>> a mask to the constructor, and calling "callParamCallbacks()" every
> time
>>> your driver gets a new value for that input. No need to worry about
> the
>>> mechanics of doing the callbacks like I showed in my previous
> message.
>>
>> The code is rather old and not written by me. I still need to poke
>> around a bit to fully comprehend the driver code flow. I guess
> complete
>> driver could be rewritten to eliminate the need to manually (in a
> loop)
>> check statically assigned port numbers, and use more appropriate Asyn
>> methods.
>>
>> Thanks!
>>
>> Best regards,
>> Hinko
>>
>>
>>
>>>
>>> Mark
>>>
>>>
>>> -----Original Message-----
>>> From: Hinko Kocevar [mailto:[email protected]]
>>> Sent: Tuesday, May 11, 2010 11:08 AM
>>> To: Mark Rivers
>>> Cc: [email protected]
>>> Subject: Re: No monitor refresh
>>>
>>> Hello Mark,
>>>
>>> On 05/11/10 16:55, Mark Rivers wrote:
>>>> As Ralph pointed out, you have set SCAN=I/O Intr. For this to work
>>> your
>>>> asyn port driver (called ENV in your case) must do callbacks to
> device
>>>> support when it receives a new value. Does this driver do so?
>>>
>>> Yes it does. I can confirm that the value indeed does change in lower
>>> levels. Even caput response is showing new value. Also when
> (re)starting
>>> the camonitor the first value shown is always prompt and correct!
>>>
>>>>
>>>> You can get information about this by typing
>>>>
>>>> asynReport 10 ENV
>>>
>>> Here is the output - I've stripped 100 or more records not to clutter
>>> the post.
>>>
>>> epics> asynReport 10 ENV
>>> ENV multiDevice:Yes canBlock:No autoConnect:Yes
>>> enabled:Yes connected:Yes numberConnects 1
>>> nDevices 89 nQueued 0 blocked:No
>>> asynManagerLock:No synchronousLock:No
>>> exceptionActive:No exceptionUsers 0 exceptionNotifys 0
>>> interposeInterfaceList
>>> asynOctet pinterface 0x40086024 drvPvt 0x1b4c8
>>> interfaceList
>>> asynCommon pinterface 0x4003c548 drvPvt 0x2b710
>>> asynInt32 pinterface 0x4003c9ac drvPvt 0x2b710
>>> asynUInt32Digital pinterface 0x4003c990 drvPvt 0x2b710
>>> asynOctet pinterface 0x4003c964 drvPvt 0x2b710
>>>
>>> ...
>>>
>>> addr 725 autoConnect Yes enabled Yes connected Yes
> exceptionActive
>>> No
>>> exceptionActive No exceptionUsers 0 exceptionNotifys 0
>>> blocked No
>>> ...
>>> Port: ENV
>>> lastAddress=0
>>> epics>
>>>
>>>>
>>>> That should show you what asyn clients (e.g. device support) have
>>>> registered for callbacks on which interfaces.
>>>>
>>>> What happens if you change SCAN to "1 second"?
>>>
>>> Will try!
>>>
>>> Thank you for the help!
>>>
>>> Best regards,
>>> Hinko
>>>
>>>
>>>
>>>>
>>>> Mark
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email protected]
>>>> [mailto:[email protected]] On Behalf Of Hinko Kocevar
>>>> Sent: Tuesday, May 11, 2010 9:07 AM
>>>> To: [email protected]
>>>> Subject: Re: No monitor refresh
>>>>
>>>> Hello Ralph,
>>>>
>>>> On 05/11/10 15:21, Ralph Lange wrote:
>>>>> Hello Hinko,
>>>>>
>>>>> what EPICS versions are you using for client and IOC?
>>>>
>>>> IOC and client use 3.14.10 EPICS base version.
>>>>
>>>>> Can you show a dump (dbpr <name>, 4) of the record that you are
>>>>> connecting to?
>>>>
>>>> Sure, here it is:
>>>> epics> dbpr LIBERA01:ENV:ENV_AGC_MONITOR 4
>>>> ACKS: NO_ALARM ACKT: YES ASG: ASP:
>>>> 0x00000000
>>>> BKPT: 0x00 COSV: NO_ALARM DESC: AGC DISA: 0
>>>>
>>>> DISP: 0 DISS: NO_ALARM DISV: 1 DPVT:
>>>> 0x50c72c00
>>>> DSET: 0x7c620840 DTYP: asynInt32 EIST: EISV:
>>>> NO_ALARM
>>>> EIVL: 0x0 ELST: ELSV: NO_ALARM ELVL:
> 0x0
>>>>
>>>> EVNT: 0 FFST: FFSV: NO_ALARM FFVL:
> 0x0
>>>>
>>>> FLNK:CONSTANT 0 FRST: FRSV: NO_ALARM FRVL:
> 0x0
>>>>
>>>> FTST: FTSV: NO_ALARM FTVL: 0x0 FVST:
>>>>
>>>> FVSV: NO_ALARM FVVL: 0x0 INP:INST_IO @asyn(ENV, 725,
>>> 1.0)
>>>>
>>>> LALM: 1 LCNT: 0 LSET: 0xe8752e00 MASK:
>>>> 4294967295
>>>> MLIS: 0x38d0320060d0320003000000 MLOK: 0x28700b00 MLST: 1
>>>>
>>>> NAME: LIBERA01:ENV:ENV_AGC_MONITOR NIST: NISV:
>>>> NO_ALARM
>>>> NIVL: 0x0 NOBT: 0 NSEV: NO_ALARM NSTA:
>>>> NO_ALARM
>>>> ONST: AUTO ONSV: NO_ALARM ONVL: 0x1 ORAW: 1
>>>>
>>>> PACT: 0 PHAS: 0 PINI: YES PPN:
>>>> 0x00000000
>>>> PPNR: 0x00000000 PRIO: LOW PROC: 0 PUTF: 0
>>>>
>>>> RDES: 0xa8a10300 RPRO: 0 RSET: 0x34b70a40 RVAL: 1
>>>>
>>>> SCAN: I/O Intr SDEF: 1 SDIS:CONSTANT SEVR:
>>>> NO_ALARM
>>>> SHFT: 0 SIML:CONSTANT SIMM: NO SIMS:
>>>> NO_ALARM
>>>> SIOL:CONSTANT SPVT: 0x388a2f00 STAT: NO_ALARM SVAL: 0
>>>>
>>>> SVST: SVSV: NO_ALARM SVVL: 0x0 SXST:
>>>>
>>>> SXSV: NO_ALARM SXVL: 0x0 TEST: TESV:
>>>> NO_ALARM
>>>> TEVL: 0x0 THST: THSV: NO_ALARM THVL:
> 0x0
>>>>
>>>> TIME: 2010-05-11 11:18:40.100440000 TPRO: 0 TSE: 0
>>>>
>>>> TSEL:CONSTANT TTST: TTSV: NO_ALARM TTVL:
> 0x0
>>>>
>>>> TVST: TVSV: NO_ALARM TVVL: 0x0 TWST:
>>>>
>>>> TWSV: NO_ALARM TWVL: 0x0 UDF: 0 UNSV:
>>>> NO_ALARM
>>>> VAL: 1 ZRST: MANUAL ZRSV: NO_ALARM ZRVL:
> 0x0
>>>>
>>>>
>>>>> What field of that record are you connecting to?
>>>>
>>>> I did no specify any field - so it is VAL, I guess by default.
>>>>
>>>> Thank you!
>>>>
>>>> Regards,
>>>> Hinko
>>>>
>>>>>
>>>>> Regards,
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Tue 11 May 2010 6:26:48 Hinko Kocevar wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm experiencing some strange behavior when using camonitor
> against
>>>> an
>>>>>> EPICS IOC.
>>>>>>
>>>>>> For some reason a CA_PROTO_EVENT_ADD response from IOC to CA
> client
>>>> does
>>>>>> not arrive, or arrives several minutes later after the PV value
> has
>>>>>> changed. Note that first CA_PROTO_EVENT_ADD response is seen
> always,
>>>>>> only latter CA_PROTO_EVENT_ADD responses do not arrive (or arrive
>>>> late)?!
>>>>>> This behavior is not seen always - sometimes the IOC would
> promptly
>>>>>> respond with CA_PROTO_EVENT_ADD response when needed.
>>>>>>
>>>>>> I can see the CA_PROTO_ECHO requests/responses fine on the same
>>>>>> camonitor channel link, only CA_PROTO_EVENT_ADD response is not
>>> seen.
>>>>>>
>>>>>> Inspecting the IOC I can see that the value did change (on lower
>>>> levels)
>>>>>> and caput response is also valid - updated with new value.
>>>>>>
>>>>>> I've ruled out the network problems, since the issue is raised
> even
>>>> when
>>>>>> using cross-over cable to communicate with the IOC. Actually even
> I
>>>>>> update the value in the IOC shell, the camonitor is not
> refreshed!!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Has someone experienced something similar?
>>>>>> Are there some conditions that need to fulfilled in order for IOC
> to
>>>>>> send a subsequent CA_PROTO_EVENT_ADD response(s)?
>>>>>>
>>>>>>
>>>>>>
>>>>>> TIA & HAND,
>>>>>> 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 - 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.
- References:
- Re: No monitor refresh Ralph Lange
- Re: No monitor refresh Hinko Kocevar
- RE: No monitor refresh Mark Rivers
- Re: No monitor refresh Hinko Kocevar
- RE: No monitor refresh Mark Rivers
- Re: No monitor refresh Hinko Kocevar
- Re: No monitor refresh Hinko Kocevar
- RE: No monitor refresh Mark Rivers
- Navigate by Date:
- Prev:
Re: No monitor refresh Hinko Kocevar
- Next:
Re: MAXv vs XPS Martin L. Smith
- 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: No monitor refresh Mark Rivers
- Next:
RE: No monitor refresh Jeff Hill
- 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