Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: Channel Access and channel name weirdness
From: Michael Westfall via Tech-talk <tech-talk@aps.anl.gov>
To: "tech-talk@aps.anl.gov Talk" <tech-talk@aps.anl.gov>
Date: Fri, 19 Jul 2019 16:01:17 -0400
Hi all,

We are experienceing some channel name anomalies in our systems.

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 channe (it's an ai record)l:
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?

Thanks,
--
Mike Westfall
Control Systems Software Engineer



Replies:
Re: Channel Access and channel name weirdness Johnson, Andrew N. via Tech-talk

Navigate by Date:
Prev: RE: USBTMC Device can not autoConnect Mark Rivers via Tech-talk
Next: Re: Channel Access and channel name weirdness Johnson, Andrew N. 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  <20192020 
Navigate by Thread:
Prev: Re: pasynOctetSyncIO flushing with drvAsynIPPortConfigure Hinko Kocevar via Tech-talk
Next: Re: Channel Access and channel name weirdness Johnson, Andrew N. 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  <20192020 
ANJ, 19 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·