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: Interpreting pvget -d
From: "Shankar, Murali via Tech-talk" <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Thu, 10 Dec 2020 18:05:01 +0000
Hello, 

  We have a image that I believe is being accessed thru the gateway (one in a swarm of gateways, each proxying a different VLAN). I have some funky behavior that is probably a config issue. I am trying to interpret the output of pvget -d.

Without the -d, the behavior is as follows. Sometimes, I get this (the valid response)
$ pvget -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
SL1K2:EXIT:CAM:DATA1:Pva:Image epics:nt/NTNDArray:1.0
    union value
        (none)
    codec_t codec
...

Othertimes I get this (an invalid response)
$ pvget -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
SL1K2:EXIT:CAM:DATA1:Pva:Image $

And sometimes, I get a timeout.


With a -d, the valid response looks like so
$ pvget -d -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
2020-12-10T09:50:38.242 Creating datagram socket from: 0.0.0.0:56065.
2020-12-10T09:50:38.242 Broadcast address #0: 172.21.159.255:5076. (not unicast)
2020-12-10T09:50:38.242 Broadcast address #1: 172.21.55.255:5076. (not unicast)
2020-12-10T09:50:38.242 Setting up UDP for interface 172.21.156.41/255.255.252.0, broadcast 172.21.159.255, dest <none>.
2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.156.41:5076.
2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.159.255:5076.
2020-12-10T09:50:38.242 Setting up UDP for interface 172.21.52.78/255.255.252.0, broadcast 172.21.55.255, dest <none>.
2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.52.78:5076.
2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.55.255:5076.
2020-12-10T09:50:38.242 Creating datagram socket from: 224.0.0.128:5076.
2020-12-10T09:50:38.242 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2020-12-10T09:50:38.242 Sending 76 bytes 0.0.0.0:56065 -> 172.21.159.255:5076.
2020-12-10T09:50:38.242 Sending 76 bytes 0.0.0.0:56065 -> 172.21.55.255:5076.
2020-12-10T09:50:38.242 UDP Client Rx (76) 172.21.159.255:5076 <- 172.21.156.41:56065
Waiting...
2020-12-10T09:50:38.242 UDP Client Rx (76) 172.21.55.255:5076 <- 172.21.52.78:56065
2020-12-10T09:50:38.243 UDP Client Rx (53) 0.0.0.0:56065 <- 172.21.156.251:60975
2020-12-10T09:50:38.243 Connecting to PVA server: 172.21.156.251:58333.
2020-12-10T09:50:38.243 Opening socket to PVA server 172.21.156.251:58333, attempt 1.
2020-12-10T09:50:38.243 Socket connected to PVA server: 172.21.156.251:58333.
2020-12-10T09:50:38.243 Acquiring transport to 172.21.156.251:58333.
2020-12-10T09:50:38.245 Connected to PVA server: 172.21.156.251:58333.
SL1K2:EXIT:CAM:DATA1:Pva:Image epics:nt/NTNDArray:1.0
    union value
        (none)
    codec_t codec
...
        string format
        string units
2020-12-10T09:50:38.257 Releasing TCP transport to 172.21.156.251:58333.
2020-12-10T09:50:38.258 TCP socket to 172.21.156.251:58333 is to be closed.
2020-12-10T09:50:38.258 UDP socket 0.0.0.0:0 closed.

The invalid response looks like so

$ pvget -d -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
2020-12-10T09:50:41.262 Creating datagram socket from: 0.0.0.0:36324.
2020-12-10T09:50:41.262 Broadcast address #0: 172.21.159.255:5076. (not unicast)
2020-12-10T09:50:41.262 Broadcast address #1: 172.21.55.255:5076. (not unicast)
2020-12-10T09:50:41.262 Setting up UDP for interface 172.21.156.41/255.255.252.0, broadcast 172.21.159.255, dest <none>.
2020-12-10T09:50:41.262 Creating datagram socket from: 172.21.156.41:5076.
2020-12-10T09:50:41.263 Creating datagram socket from: 172.21.159.255:5076.
2020-12-10T09:50:41.263 Setting up UDP for interface 172.21.52.78/255.255.252.0, broadcast 172.21.55.255, dest <none>.
2020-12-10T09:50:41.263 Creating datagram socket from: 172.21.52.78:5076.
2020-12-10T09:50:41.263 Creating datagram socket from: 172.21.55.255:5076.
2020-12-10T09:50:41.263 Creating datagram socket from: 224.0.0.128:5076.
2020-12-10T09:50:41.263 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2020-12-10T09:50:41.263 Sending 76 bytes 0.0.0.0:36324 -> 172.21.159.255:5076.
2020-12-10T09:50:41.263 Sending 76 bytes 0.0.0.0:36324 -> 172.21.55.255:5076.
2020-12-10T09:50:41.263 UDP Client Rx (76) 172.21.159.255:5076 <- 172.21.156.41:36324
Waiting...
2020-12-10T09:50:41.263 UDP Client Rx (76) 172.21.55.255:5076 <- 172.21.52.78:36324
2020-12-10T09:50:41.263 UDP Client Rx (53) 0.0.0.0:36324 <- 172.21.156.251:60975
2020-12-10T09:50:41.263 Connecting to PVA server: 172.21.156.251:58333.
2020-12-10T09:50:41.263 Opening socket to PVA server 172.21.156.251:58333, attempt 1.
2020-12-10T09:50:41.264 Socket connected to PVA server: 172.21.156.251:58333.
2020-12-10T09:50:41.264 Acquiring transport to 172.21.156.251:58333.
2020-12-10T09:50:41.266 Connected to PVA server: 172.21.156.251:58333.
2020-12-10T09:50:41.266 UDP Client Rx (53) 0.0.0.0:36324 <- 172.21.156.20:48998
SL1K2:EXIT:CAM:DATA1:Pva:Image 2020-12-10T09:50:41.276 Releasing TCP transport to 172.21.156.251:58333.
2020-12-10T09:50:41.276 TCP socket to 172.21.156.251:58333 is to be closed.
2020-12-10T09:50:41.276 UDP socket 0.0.0.0:0 closed.


The only different I see is this extra 2020-12-10T09:50:41.266 UDP Client Rx (53) 0.0.0.0:36324 <- 172.21.156.20:48998 in the invalid response.


How would I interpret this? I think we are taking to the same gateway (TCP socket to 172.21.156.251:58333 ) but I can't explain the two different responses. Any help is appreciated.

Regards,
Murali

Replies:
Re: Interpreting pvget -d Michael Davidsaver via Tech-talk
Navigate by Date:
Prev: RE: Faster Scan Rates possible? wduckitt via Tech-talk
Next: Timestamping Confusion Manoussakis, Adamandios 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: RE: Faster Scan Rates possible? wduckitt via Tech-talk
Next: Re: Interpreting pvget -d Michael Davidsaver 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, 11 Dec 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·