Re: caget: Identical process variable names on multiple servers

["Smith, Martin via Tech-talk" <tech-talk@aps.anl.gov>]

Hi Lewis,

I think that this is happening because your PV name starts with a capital letter. At APS PVs that start with a

capital letter are usually accelerator PVs so the PV gateway for your beamline lets that through. Although

This should not be getting back through the reverse PV gateway but seems that it is. So the PV appears to be

a duplicate I would guess because the PV gateway probably shows it has one and your IOC says that it has

one. 

The thing I think that you would want to note is which CA server did it actually connect to and which got ignored.

At APS beamline PVs should start with either with a lower case letter or a number which will help prevent this 

sort of thing from happening.

If you want to have a private conversation about this I would be happy to look into this issue for you.

As far as if you are getting strange IP addresses I'm not sure what that is about.

Thanks,

Marty Smith

---

From: Tech-talk <tech-talk-bounces@aps.anl.gov> on behalf of Guruswamy, Tejas via Tech-talk <tech-talk@aps.anl.gov>
Sent: Tuesday, November 11, 2025 12:21 PM
To: Muir, John Lewis <jlmuir@imca-cat.org>
Cc: EPICS Tech-Talk <tech-talk@aps.anl.gov>
Subject: Re: caget: Identical process variable names on multiple servers

 

Hi Lewis,

The message you quoted (Warning: "Identical process variable names on multiple servers") is a warning and is not fatal. By itself it does not indicate that caget will return a non-zero status.  However the fact that it appeared once and then disappeared again suggests something had temporarily changed about your network configuration or access (a gateway started/stopped responding, a router forwarded something it usually doesn't, ...), which could be the underlying reason for the failure.

Did your message really refer to the ip:port 0.0.0.1:5 ?

Almost exclusively the 0.0.0.0/8 subnet is used by hosts which are trying to discover their correct address (for example, DHCP requests always come from 0.0.0.0). But I've never seen 0.0.0.1, nor an application intentionally running on port 5.

Is it possible something had a momentary glitch and you got a corrupted packet? It would have to be something like the packet data being interpreted as the header. Not sure how that could happen and still pass checksums, but I also don't see how you can get that weird ip/port combo through any intentional network configuration.

(Proof the warning is harmless to caget's exit status:

$ caget Eiger4m:alive ; echo $?

Eiger4m:alive               57105

CA.Client.Exception...............................................

    Warning: "Identical process variable names on multiple servers"

    Context: "Channel: "Eiger4m:alive", Connecting to: zzz:5064, Ignored: yyy:5064"

    Source File: ../cac.cpp line 1321

    Current Time: Tue Nov 11 2025 12:06:15.117025996

..................................................................

CA.Client.Exception...............................................

    Warning: "Identical process variable names on multiple servers"

    Context: "Channel: "Eiger4m:alive", Connecting to: zzz:5064, Ignored: yyy:5064"

    Source File: ../cac.cpp line 1321

    Current Time: Tue Nov 11 2025 12:06:15.117080077

..................................................................

0

)

Tejas Guruswamy

APS, XSD-DET

Argonne National Laboratory

---

From: Tech-talk <tech-talk-bounces@aps.anl.gov> on behalf of J. Lewis Muir via Tech-talk <tech-talk@aps.anl.gov>
Sent: Monday, November 10, 2025 9:01 PM
To: Paul Sichta <psichta@pppl.gov>
Cc: EPICS Tech-Talk <tech-talk@aps.anl.gov>
Subject: Re: caget: Identical process variable names on multiple servers

 

On 11/10, Paul Sichta wrote:
> Lewis,

Hi, Paul!

Thank you for your reply.

> For the  "Identical PV" message:
> Is there a gateway on the 10.0.9 subnet that could be using ioc23 as a
> client?

No.  However, there is a CA gateway on 192.168.0.2, which is provided by
the APS, and which is listed in EPICS_CA_ADDR_LIST; ioc23 connects to
that for some PVs.  Could that be a problem?

(And of course, the strange thing is that this is very rare.  Out of
thousands of times running this command, it failed just this one time.)

> Your  10.0.9.255  is a broadcast.
>   0.0.0.2:5, is not in your ADDR_LIST,  so why is it answering your call?
 
Indeed.  And the same for 0.0.0.1:5.  I have no idea what that is.  The
0.0.0.0/8 network doesn't even exist on my infrastructure.

Thanks,

Lewis