Re: No monitor refresh

[Hinko Kocevar <hinko.kocevar@i-tech.si>]

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!

> 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:hinko.kocevar@i-tech.si] 
> Sent: Tuesday, May 11, 2010 11:08 AM
> To: Mark Rivers
> Cc: tech-talk@aps.anl.gov
> 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: tech-talk-bounces@aps.anl.gov
>> [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Hinko Kocevar
>> Sent: Tuesday, May 11, 2010 9:07 AM
>> To: tech-talk@aps.anl.gov
>> 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: hinko.kocevar@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.