EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Channel Access and channel name weirdness
From: "Johnson, Andrew N. via Tech-talk" <[email protected]>
To: Michael Westfall <[email protected]>, "[email protected] Talk" <[email protected]>
Date: Fri, 19 Jul 2019 21:38:20 +0000
Hi Mike,

On 7/19/19 3:01 PM, Michael Westfall via Tech-talk wrote:
I have Wireshark sniffing our control network to monitor Channel Access packets.
It's showing CA requests for channels that don't exist such as this one:
Channel Access
    Command: Search (0x0006)
    Payload Size: 24
    Reply: Only for Success (0x0005)
    Version: 13
    Client Channel ID: 94
    Param 2: 0x0000005e
    PV Name: sad:dc:d_gdr_winYo4

The channel that is being searched for, sad:dc:d_gdr_winYo4 does not exist in any of our systems, but the name is missing a prefix for a legitimate channel, and it should be gsaoi:sad:dc:d_gdr_winSizeS. This channel is referenced as an input link to a different channel (it's an ai record):
tcs-cp-ioc> dbpr tcs:drives:odgwextent 10
ACKS: INVALID       ACKT: YES           ADEL: 0             ALST: 16            
AOFF: 0             ASG:                ASLO: 1             ASP: 0x0            
BKPT: 00            DESC: Extent of ODGW window             DISA: 0            
DISP: 0             DISS: NO_ALARM      DISV: 1             DPVT: 0x28b458      
DSET: 0x28b458      DTYP: Soft Channel  EGU: pixels         EGUF: 0            
EGUL: 0             EOFF: 0             ESLO: 1             EVNT: 0            
FLNK:DB_LINK tcs:drives:odgw1x.VAL      HHSV: NO_ALARM      HIGH: 0            
HIHI: 0             HOPR: 0             HSV: NO_ALARM       HYST: 0            
INIT: 0             INP:CA_LINK gsaoi:sad:dc:d_gdr_winSizeS CA NMS              
LALM: 16            LBRK: 0             LCNT: 0             LINR: LINEAR        
LLSV: NO_ALARM      LOLO: 0             LOPR: 0             LOW: 0              
LSET: 0x1c9c7e0     LSV: NO_ALARM       MDEL: 0            
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00                   MLOK: 01 8b c9 18  
MLST: 16            NAME: tcs:drives:odgwextent             NSEV: NO_ALARM      
NSTA: NO_ALARM      ORAW: 0             PACT: 0             PBRK: 0x0          
PHAS: 0             PINI: NO            PPN: 0x0            PPNR: 0x0          
PREC: 1             PRIO: LOW           PROC: 0             PUTF: 0            
RDES: 0xae1f78      ROFF: 0             RPRO: 0             RSET: 0x28ac30      
RVAL: 0             SCAN: 2 second      SDIS:CONSTANT 0.000000000000000e+00    
SEVR: NO_ALARM      SIML:CONSTANT 0.000000000000000e+00     SIMM: NO            
SIMS: NO_ALARM      SIOL:CONSTANT 0.000000000000000e+00     SMOO: 0            
SPVT: 0x1d01758     STAT: NO_ALARM      SVAL: 0            
TIME: 2019-07-19 15:41:03.662545919     TPRO: 0             TSE: 0              
TSEL:CONSTANT       UDF: 0              VAL: 16            
tcs-cp-ioc>

The channel requesting the value ( tcs:drives:odgwextent) does seem to be getting the correct input value from the other channel (gsaoi:sad:dc:d_gdr_winSizeS):
$ caget gsaoi:sad:dc:d_gdr_winSizeS
gsaoi:sad:dc:d_gdr_winSizeS    16
$ caget  tcs:drives:odgwextent
tcs:drives:odgwextent          16

but as can be seen from the Wireshark capture, CA is also requesting the channel with an incomplete version of its name.

The channel with the bogus name (and several others) is being asked for many times per second, and we are concerned about unnecessary network traffic.

For reference, we are using EPICS R3.14.12.8 with RTEMS 4.10.2 on a MVME2700 CPU.


Can someone help us understand what's going on here?
How do you know what client is requesting those names? My guess is it may be a sequence program (or maybe a PV named in an access security file) running on the same IOC which hasn't been given the right prefix.

The 'dbcar' command lists the IOC's dbCa links, and can confirm or deny that it's a database link (use dbcar "*", 0/1/2 to see increasing amounts of info). You'll need to use the sequencer commands seqShow and seqChanShow to check for unconnected channels for your sequence programs, I forget what the arguments are to seqChanShow but I think you give it a program name and "-" to see only disconnected channels. There is also a similar 'ascar <level>' command for reporting CA connections if you're using access security.

HTH,

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.
Replies:
Re: Channel Access and channel name weirdness Michael Westfall via Tech-talk
References:
Channel Access and channel name weirdness Michael Westfall via Tech-talk
Navigate by Date:
Prev: Channel Access and channel name weirdness Michael Westfall via Tech-talk
Next: Compress Record with input from partial Waveform Bruno Martins via Tech-talk
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: Channel Access and channel name weirdness Michael Westfall via Tech-talk
Next: Re: Channel Access and channel name weirdness Michael Westfall via Tech-talk
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, 22 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·