EPICS Tech-talk mailing list

Re: CSS Phoebus integration

Luis Alberto De Sousa Moreira via Tech-talk — Mon, 03 Aug 2026 10:59:11 GMT

Subject:	Re: CSS Phoebus integration
From:	Luis Alberto De Sousa Moreira via Tech-talk <tech-talk at aps.anl.gov>
To:	"Kasemir, Kay" <kasemirk at ornl.gov>, GAGET Alexis <ALEXIS.GAGET at cea.fr>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Mon, 3 Aug 2026 12:59:11 +0200

Hi Guys,
Thank you for the suggestions, having a look at the options at the moment.

Kind Regards
Luis

On 29/07/2026 13:49, Kasemir, Kay wrote:

Another option might be the creation of a “library”.

Create valves etc. by combining triangles etc. as shown in Alexis’ example.

Group them so that each “Valve”, “Sensor”, … is a group.

Save that display, make the file read-only.

When you now open that file in the editor, you can’t edit it be because it’s read-only. You can, however, select/copy elements from that read-only editor pane and paste them into another editor.

Your read-only file thus becomes a library from which you can copy/paste a “valve”, “sensor” etc. into a new display.

-- 
Luis Moreira
EPFL SB SPC-II, PPH241 (Batiment PPH) Station 13
CH-1015 Lausanne, Switzerland
Tel.    (+41) 21 693 58 37
E-Mail  luis.moreira at epfl.ch

Re: CSS Phoebus integration

Ralph Lange via Tech-talk — Mon, 03 Aug 2026 11:59:44 GMT

Subject:	Re: CSS Phoebus integration
From:	Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To:	EPICS Tech Talk <tech-talk at aps.anl.gov>
Date:	Mon, 3 Aug 2026 13:59:44 +0200

I remember that ITER made its "industrial look" symbol library available at some point (a few years ago). Is that still in or was it dropped later on?

Cheers,
~Ralph

[Katy In Control] S1E02 — Same Death Star, Different Blueprints 🚀

SAINTIN Katy via Tech-talk — Tue, 04 Aug 2026 02:59:11 GMT

Subject:	[Katy In Control] S1E02 — Same Death Star, Different Blueprints 🚀
From:	SAINTIN Katy via Tech-talk <tech-talk at aps.anl.gov>
To:	tech-talk <tech-talk at aps.anl.gov>
Date:	Tue, 4 Aug 2026 02:59:11 +0000

Dear EPICS community,

You asked. Here it is. 😄

Several of you reached out after Episode 1 to ask when Episode 2 would be out — so I'm very happy to announce that it's now available:

🎬 S1E02 — Same Death Star, Different Blueprints

TANGO & EPICS — told the Star Wars way

In this episode, I go deeper into the galaxy you know best.

Droids. Holograms. The brain of operations.

But this time, two blueprints side by side — no spoilers, no jargon dropped without explanation, and no tribalism.

Each episode now comes with:

📄 A companion PDF guide — downloadable and shareable

🌐 A full online guide with glossary and cross-referenced navigation

🏠 A central hub for all episodes: https://katysaintin.github.io/KatyInControl

🎥 Episode 2 on YouTube:

https://youtu.be/fiTxTRIKiLE

---

And a word about Episode 3 — coming up next.

Every great system has an origin story.

Who built EPICS? In which basement? On which machine? And why?

I'm currently reaching out to the people who were there at the beginning — to collect the anecdotes, the memories, and the stories that deserve to be told.

If you have a story to share, or know someone I should talk to — I'd love to hear from you.

Looking forward to seeing many of you at future EPICS meetings and ICALEPCS.

May the uptime be with you 🚀

Best regards,

Katy Saintin

De : SAINTIN Katy
Envoyé : mercredi 20 mai 2026 21:34
À : tech-talk
Objet : [Katy In Control] S1E01 — Understand SCADA, You Must 🚀

Dear EPICS community,

Although I unfortunately missed the last EPICS meeting at CEA this April due to an Achilles tendon rupture, I followed the event from afar and I am already looking forward to reconnecting with the community soon 😊

In the meantime, I wanted to share a new personal project I recently launched:

🎙️ “Katy In Control”

After years working between TANGO and EPICS environments, I wanted to create something that helps explain industrial control systems and SCADA architectures in a simpler and more accessible way — especially for younger engineers and newcomers entering our field.

So naturally… I started with Star Wars 😄

🎬 S1E01 — Understand SCADA, You Must
EPICS & TANGO Revealed

In this first episode:
🔧 Hardware
📡 Communication Bus
🧠 Business Logic

…explained through the architecture of a galaxy far, far away.

This project is also my way of helping bridge worlds:
- EPICS & TANGO
- IT & OT
- controls & software engineering
- experts & newcomers

May the uptime be with you 🚀

🎥 YouTube:
https://youtu.be/aU-Z3XFPA_A

Very happy to already see encouraging reactions from members of the EPICS community 😊

Looking forward to seeing many of you again at future meetings and ICALEPCS.

Best regards,

Katy SAINTIN

Ingénieur chercheur en développement logiciel - Programmation Orientée Objet

Software research engineer - Object-Oriented Programming

________________________________________________

DRF/IRFU/DIS/LDISC

01 69 08 72 04 / 06 08 91 42 77

Bât 472 pièce 107

CEA SACLAY 91191 Gif s/Yvette CEDEX

Avant d'imprimer, pensez à l'environnement

Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

Usharani Kandula via Tech-talk — Tue, 04 Aug 2026 15:59:04 GMT

Subject:	Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)
From:	Usharani Kandula via Tech-talk <tech-talk at aps.anl.gov>
To:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Tue, 4 Aug 2026 15:59:04 +0000

Hello Team,

I’m looking for guidance on a Java PVA client use case where I already know the IOC endpoint for a PV (resolved via an internal lookup/database), and I want to connect directly to that IOC and read the PV without performing any PVA search.

Goal / Requirement

Given:

- PV name (example: `ABC:TEMP`)

- Known IOC endpoint (example: `127.0.0.1:5075`)

I want:

- No UDP multicast search

- No UDP unicast search

- No TCP directed search (i.e., avoid the `EPICS_PVA_NAME_SERVERS` search step)

- Instead: direct TCP connect + CreateChannel + read

In other words, since my internal lookup already tells me where the PV lives, I want to avoid asking the IOC again “do you have this PV?”

What I tried

1) Standard configuration to disable multicast/broadcast

I can disable multicast/broadcast discovery via:

```

EPICS_PVA_AUTO_ADDR_LIST=NO

EPICS_PVA_ADDR_LIST=

```

But the remaining supported approach is to use `EPICS_PVA_NAME_SERVERS=host:port`, which performs a directed TCP search. That still sends a search request to the IOC.

2) core-pva (Phoebus) low-level POC that skips search entirely

I built a proof-of-concept using `org.phoebus:core-pva:5.0.5` that successfully reads a PV from a known endpoint without any search.

High-level summary of the POC:

- Creates a `PVAClient`

- Creates a `PVAChannel`

- Unregisters it from search

- Creates a direct TCP handler to the known IOC endpoint

- Manually sets channel state to FOUND

- Registers the channel with the TCP handler (sends CreateChannelRequest)

- Connects and reads

This works (tested against a Python fake IOC), but it relies on package-private/internal APIs such as:

- `ClientTCPHandler`

- `ClientChannelState`

- `PVAChannel.setState()`

- `PVAChannel.registerWithServer()`

- `client.search.unregister()`

To access these, the POC code is placed in the same Java package as the library (`org.epics.pva.client`), which is not ideal for production.

Questions

1. Is there a supported/public Java API (in core-pva or elsewhere) to do a true direct connect to a known IOC endpoint without any search?

2. If not, would the community consider a change to core-pva to add a public API such as:

```java

PVAChannel connectDirect(String pvName, InetSocketAddress iocAddress)

```

that encapsulates the internal wiring currently required?

3. Are there protocol-level concerns with skipping search entirely (e.g., server GUID handling, channel lifecycle expectations) that would make this approach problematic?

Additional details

- Library: `org.phoebus:core-pva:5.0.5`

- Java: 21

- Current POC output shows successful connect/read and prints the returned `PVAStructure`.

Thanks in advance for any guidance.

Best regards,

Usharani

Fermi National Accelerator Laboratory

Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

White, Greg R. via Tech-talk — Tue, 04 Aug 2026 16:19:39 GMT

Subject:	Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)
From:	"White, Greg R. via Tech-talk" <tech-talk at aps.anl.gov>
To:	Usharani Kandula <ukandula at fnal.gov>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Tue, 4 Aug 2026 16:19:39 +0000

Hi Usharani, the first implementations of pvaccess for Java, pvAccessJava and pvDataJava did exactly what you want- as I understand it to be. I think there is an example in the Normative Types document for the type NTURI. Maybe that functionality has made it into more recent implementations. I hope so.

Cheers

Greg

On Aug 4, 2026, at 9:00 AM, Usharani Kandula via Tech-talk wrote:

Hello Team,

I’m looking for guidance on a Java PVA client use case where I already know the IOC endpoint for a PV (resolved via an internal lookup/database), and I want to connect directly to that IOC and read the PV without performing any PVA search.

Goal / Requirement

Given:

- PV name (example: `ABC:TEMP`)

- Known IOC endpoint (example: `127.0.0.1:5075`)

I want:

- No UDP multicast search

- No UDP unicast search

- No TCP directed search (i.e., avoid the `EPICS_PVA_NAME_SERVERS` search step)

- Instead: direct TCP connect + CreateChannel + read

In other words, since my internal lookup already tells me where the PV lives, I want to avoid asking the IOC again “do you have this PV?”

What I tried

1) Standard configuration to disable multicast/broadcast

I can disable multicast/broadcast discovery via:

```

EPICS_PVA_AUTO_ADDR_LIST=NO

EPICS_PVA_ADDR_LIST=

```

But the remaining supported approach is to use `EPICS_PVA_NAME_SERVERS=host:port`, which performs a directed TCP search. That still sends a search request to the IOC.

2) core-pva (Phoebus) low-level POC that skips search entirely

I built a proof-of-concept using `org.phoebus:core-pva:5.0.5` that successfully reads a PV from a known endpoint without any search.

High-level summary of the POC:

- Creates a `PVAClient`

- Creates a `PVAChannel`

- Unregisters it from search

- Creates a direct TCP handler to the known IOC endpoint

- Manually sets channel state to FOUND

- Registers the channel with the TCP handler (sends CreateChannelRequest)

- Connects and reads

This works (tested against a Python fake IOC), but it relies on package-private/internal APIs such as:

- `ClientTCPHandler`

- `ClientChannelState`

- `PVAChannel.setState()`

- `PVAChannel.registerWithServer()`

- `client.search.unregister()`

To access these, the POC code is placed in the same Java package as the library (`org.epics.pva.client`), which is not ideal for production.

Questions

1. Is there a supported/public Java API (in core-pva or elsewhere) to do a true direct connect to a known IOC endpoint without any search?

2. If not, would the community consider a change to core-pva to add a public API such as:

```java

PVAChannel connectDirect(String pvName, InetSocketAddress iocAddress)

```

that encapsulates the internal wiring currently required?

3. Are there protocol-level concerns with skipping search entirely (e.g., server GUID handling, channel lifecycle expectations) that would make this approach problematic?

Additional details

- Library: `org.phoebus:core-pva:5.0.5`

- Java: 21

- Current POC output shows successful connect/read and prints the returned `PVAStructure`.

Thanks in advance for any guidance.

Best regards,

Usharani

Fermi National Accelerator Laboratory

Re: AreaDetector Collaboration Meeting - August 6th

Henrique F. Simoes via Tech-talk — Tue, 04 Aug 2026 21:19:12 GMT

Subject:	Re: AreaDetector Collaboration Meeting - August 6th
From:	"Henrique F. Simoes via Tech-talk" <tech-talk at aps.anl.gov>
To:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Tue, 4 Aug 2026 21:19:12 +0000

Hi folks!

This month's meeting will be on August 6th at 15:00 UTC. Some useful
links are available below. If attendants (and anyone else who's
interested) could take a look at the agenda - and act on relevant items
if possible - before the meeting, that would be greatly appreciated. If
you wish to discuss the meeting in a more informal setting, the
AreaDetector room is available in the EPICS Chat Server.

Please contact me outside tech-talk (either email or EPICS Chat) if
you'd like to be included in the invite list, so it can be in your calendar.

The repositories included in the agenda are: areaDetector, ADCore,
ADAndor, ADCSimDetector, ADDexela, ADEiger, ADLambda, ADLightField,
ADPerkinElmer, ADSBIG, ADURL, NDDriverStdArrays, epics-modules/mca,
epics-modules/xspress3, NSLS2/OceanOptics.

Useful links:

Meeting:
https://urldefense.us/v3/__https://teams.microsoft.com/l/meetup-join/19*3ameeting_ZDJlOTI1N2UtOTNhOS00NzNlLWJjNjItY2ZhYmY1MThiMWFm*40thread.v2/0?context=*7b*22Tid*22*3a*22ed764e1f-b3b8-4aaf-8fb2-1d05be08443b*22*2c*22Oid*22*3a*22d394739f-da48-4ea1-aba3-6ccf4c14ea4f*22*7d__;JSUlJSUlJSUlJSUlJSUl!!G_uCfscf7eWS!eNvb5yiy3dPZRFQNo2ZmANeG1XPISQjwxBTMihmCb3ID4Jp4iYZDNH-Zjy4Z2iqI_awREZj35h-3DkX2AnTaHOfR3cUeukV-$

EPICS Chat Server: https://urldefense.us/v3/__https://epics-controls.org/epics-chat/__;!!G_uCfscf7eWS!eNvb5yiy3dPZRFQNo2ZmANeG1XPISQjwxBTMihmCb3ID4Jp4iYZDNH-Zjy4Z2iqI_awREZj35h-3DkX2AnTaHOfR3e1AqOzM$

Meeting agenda: https://urldefense.us/v3/__https://github.com/areaDetector/collaboration/pull/4__;!!G_uCfscf7eWS!eNvb5yiy3dPZRFQNo2ZmANeG1XPISQjwxBTMihmCb3ID4Jp4iYZDNH-Zjy4Z2iqI_awREZj35h-3DkX2AnTaHOfR3bT589DO$

--
Henrique F. Simões
Control Software Group (SwC)
Brazilian Synchrotron Light Laboratory (LNLS)
Brazilian Center for Research in Energy and Materials (CNPEM)

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.

Support for MKS Microvision2 RGA?

Ralph Lange via Tech-talk — Wed, 05 Aug 2026 13:50:00 GMT

Subject:	Support for MKS Microvision2 RGA?
From:	Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To:	EPICS Tech Talk <tech-talk at aps.anl.gov>
Date:	Wed, 5 Aug 2026 15:50:00 +0200

Asking for a friend...

The MKS Microvision 2 RGA, manuals e.g. here [1], was mentioned on Tech-Talk in 2016 by Dave Hickin. The Device Support he describes there seems to be available on GitHub under the Diamond org [2].

Is that code still in use?

Is there something else for this device?

Who at Diamond would be a good contact person for questions?

Thanks a lot!

~Ralph

[1] https://mmrc.caltech.edu/Kratos%20XPS/MKS%20RGA/MKS.html

[2] https://github.com/DiamondLightSource/rgamv2

Re: Support for MKS Microvision2 RGA?

Henrique F. Simoes via Tech-talk — Wed, 05 Aug 2026 18:16:49 GMT

Subject:	Re: Support for MKS Microvision2 RGA?
From:	"Henrique F. Simoes via Tech-talk" <tech-talk at aps.anl.gov>
To:	Ralph Lange <ralph.lange at gmx.de>
Cc:	Tech Talk <tech-talk at aps.anl.gov>
Date:	Wed, 5 Aug 2026 18:16:49 +0000

Hi, Ralph.

On Wed Aug 5, 2026 at 10:50 AM -03, Ralph Lange via Tech-talk wrote:
> Asking for a friend...

Answering on behalf of a friend as well... ;)

> The MKS Microvision 2 RGA, manuals e.g. here [1], was mentioned on
> Tech-Talk in 2016 by Dave Hickin. The Device Support he describes there
> seems to be available on GitHub under the Diamond org [2].

We at Sirius don't have an MKS Microvision 2 RGA, but rather an e-Vision
2. Fortunately, the Diamond's driver works mostly fine for our device.
We only needed to patch the initialization logic for analog input/output
as our device doesn't provide this feature [3].

By the way, we welcome any help on further validating the changes
proposed in the pull request.

[3] github.com/DiamondLightSource/rgamv2/pull/1

> Is that code still in use?

We are running the patched version in one of our beamlines under
commissioning since March. Everything seems to be working fine.

> Is there something else for this device?

I don't know.

> Who at Diamond would be a good contact person for questions?

Giles Knap answered us promptly in our PR at the time. I'm taking the
liberty to CC him.

I hope this helps.

--
Henrique F. Simões
Control Software Group (SwC)
Brazilian Synchrotron Light Laboratory (LNLS)
Brazilian Center for Research in Energy and Materials (CNPEM)

> Thanks a lot!
> ~Ralph
>
> [1] https://urldefense.us/v3/__https://mmrc.caltech.edu/Kratos*20XPS/MKS*20RGA/MKS.html__;JSU!!G_uCfscf7eWS!b5Hi8qhxP6UbM0KzU1mASHeQgbqZKB_pBjpOO7NXX5oSly7ZmQAUF2DnmTcG4Xbt5631PByJpMHg2hQbsjs5JyxYpxw$
> [2] https://urldefense.us/v3/__https://github.com/DiamondLightSource/rgamv2__;!!G_uCfscf7eWS!b5Hi8qhxP6UbM0KzU1mASHeQgbqZKB_pBjpOO7NXX5oSly7ZmQAUF2DnmTcG4Xbt5631PByJpMHg2hQbsjs5VrzH66Y$

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.

Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

Abdalla Ahmad via Tech-talk — Thu, 06 Aug 2026 05:49:14 GMT

Subject:	Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)
From:	Abdalla Ahmad via Tech-talk <tech-talk at aps.anl.gov>
To:	Usharani Kandula <ukandula at fnal.gov>, "White, Greg R." <greg at slac.stanford.edu>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Thu, 6 Aug 2026 05:49:14 +0000

Is it possible to do the same in channel access? i.e. Avoid UDP and TCP search and going directly to TCP connect?

Best Regards,

Abdalla

From: Tech-talk on behalf of White, Greg R. via Tech-talk
Sent: Tuesday, August 4, 2026 7:19 PM
To: Usharani Kandula
Cc: tech-talk at aps.anl.gov
Subject: Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

Cheers

Greg

On Aug 4, 2026, at 9:00 AM, Usharani Kandula via Tech-talk wrote:

Hello Team,

I’m looking for guidance on a Java PVA client use case where I already know the IOC endpoint for a PV (resolved via an internal lookup/database), and I want to connect directly to that IOC and read the PV without performing any PVA search.

Goal / Requirement

Given:

- PV name (example: `ABC:TEMP`)

- Known IOC endpoint (example: `127.0.0.1:5075`)

I want:

- No UDP multicast search

- No UDP unicast search

- No TCP directed search (i.e., avoid the `EPICS_PVA_NAME_SERVERS` search step)

- Instead: direct TCP connect + CreateChannel + read

In other words, since my internal lookup already tells me where the PV lives, I want to avoid asking the IOC again “do you have this PV?”

What I tried

1) Standard configuration to disable multicast/broadcast

I can disable multicast/broadcast discovery via:

```

EPICS_PVA_AUTO_ADDR_LIST=NO

EPICS_PVA_ADDR_LIST=

```

But the remaining supported approach is to use `EPICS_PVA_NAME_SERVERS=host:port`, which performs a directed TCP search. That still sends a search request to the IOC.

2) core-pva (Phoebus) low-level POC that skips search entirely

I built a proof-of-concept using `org.phoebus:core-pva:5.0.5` that successfully reads a PV from a known endpoint without any search.

High-level summary of the POC:

- Creates a `PVAClient`

- Creates a `PVAChannel`

- Unregisters it from search

- Creates a direct TCP handler to the known IOC endpoint

- Manually sets channel state to FOUND

- Registers the channel with the TCP handler (sends CreateChannelRequest)

- Connects and reads

This works (tested against a Python fake IOC), but it relies on package-private/internal APIs such as:

- `ClientTCPHandler`

- `ClientChannelState`

- `PVAChannel.setState()`

- `PVAChannel.registerWithServer()`

- `client.search.unregister()`

To access these, the POC code is placed in the same Java package as the library (`org.epics.pva.client`), which is not ideal for production.

Questions

1. Is there a supported/public Java API (in core-pva or elsewhere) to do a true direct connect to a known IOC endpoint without any search?

2. If not, would the community consider a change to core-pva to add a public API such as:

```java

PVAChannel connectDirect(String pvName, InetSocketAddress iocAddress)

```

that encapsulates the internal wiring currently required?

3. Are there protocol-level concerns with skipping search entirely (e.g., server GUID handling, channel lifecycle expectations) that would make this approach problematic?

Additional details

- Library: `org.phoebus:core-pva:5.0.5`

- Java: 21

- Current POC output shows successful connect/read and prints the returned `PVAStructure`.

Thanks in advance for any guidance.

Best regards,

Usharani

Fermi National Accelerator Laboratory

Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

Johnson, Andrew N. via Tech-talk — Thu, 06 Aug 2026 18:10:10 GMT

Subject:	Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)
From:	"Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>
To:	Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Thu, 6 Aug 2026 18:10:10 +0000

Hi Abdalla,

If you only have a very small number of IOCs you could configure your CA clients to connect directly to each one as a name-server by listing all of the IOC RSRV TCP sockets (IP address and the server’s TCP port number) in the EPICS_CA_NAME_SERVERS environment variable — this is described in the CA Reference Manual’s WAN Environment section. That approach is much harder to do if you run multiple IOCs on the same computer since the RSRV port numbers get picked at random after the first, so it won’t scale to many more IOCs.

You could run a CA Name Server that you point the clients to instead, so they send their name searches to that over TCP. That scales well and can work well across multiple subnets but it does require the name server to be given lists of the record names served by every IOC, and the simplest configuration allows the name-server to use UDP broadcasts to find the IOCs. The clients can be configured to not send broadcasts, and you can run multiple name-servers in parallel for increased reliability if you want.

How would the name server get the list of record names? At APS every IOC writes that list to a file on our shared NFS server every time it boots, and the name server is configured to read those files directly. Other sites use the recsync module from ChannelFinder to announce the IOC’s presence and the receiver to fetch the list from them, but that module sends UDP broadcast packets to announce the IOC’s presence, and I’m not sure if there’s a way to generate the name-list files needed by the name-server without writing extra code to query the Channel Finder database. It’s possible that there’s another name server in the community that interfaces directly to the Channel Finder.

IOCs also send out beacons as UDP broadcasts, which help clients know when an IOC comes online. Without those, client channels don’t reconnect as quickly as they do with the beacons.

For a large control system using CA to run completely free of UDP is tricky.

HTH,

- Andrew

Complexity comes for free, Simplicity you have to work for.

On 8/6/26, 12:49 AM, "Tech-talk" wrote:

Is it possible to do the same in channel access? i.e. Avoid UDP and TCP search and going directly to TCP connect?

Best Regards,

Abdalla

Cheers

Greg

On Aug 4, 2026, at 9:00 AM, Usharani Kandula via Tech-talk wrote:

Hello Team,

I’m looking for guidance on a Java PVA client use case where I already know the IOC endpoint for a PV (resolved via an internal lookup/database), and I want to connect directly to that IOC and read the PV without performing any PVA search.

Goal / Requirement

Given:

- PV name (example: `ABC:TEMP`)

- Known IOC endpoint (example: `127.0.0.1:5075`)

I want:

- No UDP multicast search

- No UDP unicast search

- No TCP directed search (i.e., avoid the `EPICS_PVA_NAME_SERVERS` search step)

- Instead: direct TCP connect + CreateChannel + read

In other words, since my internal lookup already tells me where the PV lives, I want to avoid asking the IOC again “do you have this PV?”

What I tried

1) Standard configuration to disable multicast/broadcast

I can disable multicast/broadcast discovery via:

```

EPICS_PVA_AUTO_ADDR_LIST=NO

EPICS_PVA_ADDR_LIST=

```

But the remaining supported approach is to use `EPICS_PVA_NAME_SERVERS=host:port`, which performs a directed TCP search. That still sends a search request to the IOC.

2) core-pva (Phoebus) low-level POC that skips search entirely

I built a proof-of-concept using `org.phoebus:core-pva:5.0.5` that successfully reads a PV from a known endpoint without any search.

High-level summary of the POC:

- Creates a `PVAClient`

- Creates a `PVAChannel`

- Unregisters it from search

- Creates a direct TCP handler to the known IOC endpoint

- Manually sets channel state to FOUND

- Registers the channel with the TCP handler (sends CreateChannelRequest)

- Connects and reads

This works (tested against a Python fake IOC), but it relies on package-private/internal APIs such as:

- `ClientTCPHandler`

- `ClientChannelState`

- `PVAChannel.setState()`

- `PVAChannel.registerWithServer()`

- `client.search.unregister()`

To access these, the POC code is placed in the same Java package as the library (`org.epics.pva.client`), which is not ideal for production.

Questions

1. Is there a supported/public Java API (in core-pva or elsewhere) to do a true direct connect to a known IOC endpoint without any search?

2. If not, would the community consider a change to core-pva to add a public API such as:

```java

PVAChannel connectDirect(String pvName, InetSocketAddress iocAddress)

```

that encapsulates the internal wiring currently required?

3. Are there protocol-level concerns with skipping search entirely (e.g., server GUID handling, channel lifecycle expectations) that would make this approach problematic?

Additional details

- Library: `org.phoebus:core-pva:5.0.5`

- Java: 21

- Current POC output shows successful connect/read and prints the returned `PVAStructure`.

Thanks in advance for any guidance.

Best regards,

Usharani

Fermi National Accelerator Laboratory

Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

Ralph Lange via Tech-talk — Fri, 07 Aug 2026 07:57:51 GMT

Subject:	Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)
From:	Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To:	EPICS Tech Talk <tech-talk at aps.anl.gov>
Date:	Fri, 7 Aug 2026 09:57:51 +0200

Well, the protocol assumes you resolve the PV name before connecting, so all widely-used CA client libraries hard-wire this process.

Looking at the caproto pure Python client, it seems you could directly open the TCP connection. I've never tried this, so my statement is solely based on looking at the doc.

What's your motivation?

PV name resolution is a one-off procedure at the beginning of a connection. If you point EPICS_CA_NAME_SERVERS to your IOC host:port, the name resolution is adding one query-response pair of messages. That's not much to pay for robustness. (If multiple IOCs are running on a host, rebooting one will change its CA port number.)

Cheers,
~Ralph

On Thu, 6 Aug 2026 at 07:49, Abdalla Ahmad via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hi

Is it possible to do the same in channel access? i.e. Avoid UDP and TCP search and going directly to TCP connect?

Best Regards,

Abdalla

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of White, Greg R. via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, August 4, 2026 7:19 PM
To: Usharani Kandula <ukandula at fnal.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

Hi Usharani, the first implementations of pvaccess for Java, pvAccessJava and pvDataJava did exactly what you want- as I understand it to be. I think there is an example in the Normative Types document for the type NTURI. Maybe that functionality has made it into more recent implementations. I hope so.

Cheers

Greg

On Aug 4, 2026, at 9:00 AM, Usharani Kandula via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hello Team,

I’m looking for guidance on a Java PVA client use case where I already know the IOC endpoint for a PV (resolved via an internal lookup/database), and I want to connect directly to that IOC and read the PV without performing any PVA search.

Goal / Requirement

Given:

- PV name (example: `ABC:TEMP`)

- Known IOC endpoint (example: `127.0.0.1:5075`)

I want:

- No UDP multicast search

- No UDP unicast search

- No TCP directed search (i.e., avoid the `EPICS_PVA_NAME_SERVERS` search step)

- Instead: direct TCP connect + CreateChannel + read

In other words, since my internal lookup already tells me where the PV lives, I want to avoid asking the IOC again “do you have this PV?”

What I tried

1) Standard configuration to disable multicast/broadcast

I can disable multicast/broadcast discovery via:

```

EPICS_PVA_AUTO_ADDR_LIST=NO

EPICS_PVA_ADDR_LIST=

```

But the remaining supported approach is to use `EPICS_PVA_NAME_SERVERS=host:port`, which performs a directed TCP search. That still sends a search request to the IOC.

2) core-pva (Phoebus) low-level POC that skips search entirely

I built a proof-of-concept using `org.phoebus:core-pva:5.0.5` that successfully reads a PV from a known endpoint without any search.

High-level summary of the POC:

- Creates a `PVAClient`

- Creates a `PVAChannel`

- Unregisters it from search

- Creates a direct TCP handler to the known IOC endpoint

- Manually sets channel state to FOUND

- Registers the channel with the TCP handler (sends CreateChannelRequest)

- Connects and reads

This works (tested against a Python fake IOC), but it relies on package-private/internal APIs such as:

- `ClientTCPHandler`

- `ClientChannelState`

- `PVAChannel.setState()`

- `PVAChannel.registerWithServer()`

- `client.search.unregister()`

To access these, the POC code is placed in the same Java package as the library (`org.epics.pva.client`), which is not ideal for production.

Questions

1. Is there a supported/public Java API (in core-pva or elsewhere) to do a true direct connect to a known IOC endpoint without any search?

2. If not, would the community consider a change to core-pva to add a public API such as:

```java

PVAChannel connectDirect(String pvName, InetSocketAddress iocAddress)

```

that encapsulates the internal wiring currently required?

3. Are there protocol-level concerns with skipping search entirely (e.g., server GUID handling, channel lifecycle expectations) that would make this approach problematic?

Additional details

- Library: `org.phoebus:core-pva:5.0.5`

- Java: 21

- Current POC output shows successful connect/read and prints the returned `PVAStructure`.

Thanks in advance for any guidance.

Best regards,

Usharani

Fermi National Accelerator Laboratory

Display Images on .bob using DBWR

Vishnu Patel via Tech-talk — Fri, 07 Aug 2026 09:48:37 GMT

Subject:	Display Images on .bob using DBWR
From:	Vishnu Patel via Tech-talk <tech-talk at aps.anl.gov>
To:	EPICS Tech Talk <tech-talk at aps.anl.gov>
Date:	Fri, 7 Aug 2026 09:48:37 +0000

Dear Sir,

I have configured the Phoebus Display Builder Web Runtime(DBWR) to display .bob files through a web browser.

After completing the Tomcat and DBWR configuration, I am able to successfully open and display the .bob panel in the client machine web browser. However, the pictures/symbols used in the .bob file are not displayed.

The browser shows an error while trying to load these image/symbol files. It appears that DBWR is referring to the image files using a local file path on the server, which cannot be accessed by the client browser.

The browser console error is shown below.

--------------------

Loading 'file:/opt/tomcat/webapps/dbwr/LCPC/CompressorLocal.bob' with {}

dbwr.js?V=1786090605:560 New rule for w147 'background_color'

dbwr.js?V=1786090605:134 Connecting PVs

dbwr.js?V=1786090605:134 Disconnected

pvws.js?V=1786090605:30 Opening ws://10.20.120.45:8080/pvws/pv

pvws.js?V=1786090605:40 Connected to ws://10.20.120.45:8080/pvws/pv

dbwr.js?V=1786090605:134 Initialize Widgets

picture.js?V=1786090605:16 Cannot load picture from file:/opt/tomcat/webapps/dbwr/LCPC/Symbol/VR Steam Trap.png because web browser cannot access files on server.

DisplayBuilderWebRuntime.widget_init_methods.picture @ picture.js?V=1786090605:16

6picture.js?V=1786090605:16 Cannot load picture from file:/opt/tomcat/webapps/dbwr/LCPC/Symbol/Radiological Protection Screw1.png because web browser cannot access files on server.

DisplayBuilderWebRuntime.widget_init_methods.picture @ picture.js?V=1786090605:16

view.jsp?display=file:/opt/tomcat/webapps/dbwr/LCPC/CompressorLocal.bob:1 Not allowed to load local resource: file://opt/tomcat/webapps/dbwr/LCPC/Symbol/VR%20Steam%20Trap.png

---------------

The DBWR/Tomcat logs on the server is

$tail -f /opt/tomcat/logs/catalina.out

07-Aug-2026 13:46:46.276 INFO [http-nio-8080-exec-3] dbwr.rules.RuleSupport.handleRule PolygonWidget ID w147 rule:

LCPC_CRYO_COMP_C_RUN

.. turned into ..

{

// Rule 'Rule'

let rule2 = new WidgetRule('w147', 'background_color', ['LCPC_CRYO_COMP_C_RUN']);

rule2.eval = function()

{

let pv0 = this.value['LCPC_CRYO_COMP_C_RUN'];

let pvStr0 = this.valueStr['LCPC_CRYO_COMP_C_RUN'];

if (pv0==1) return '#00FF00';

if (pv0==0) return '#005500';

return '#005500';

}

rule2.update = set_svg_background_color

}

07-Aug-2026 13:46:46.290 INFO [http-nio-8080-exec-3] dbwr.servlets.DisplayCache.getOrCreate Cache created file:/opt/tomcat/webapps/dbwr/LCPC/CompressorLocal.bob {}: Load time 23ms

$tail -f /opt/tomcat/logs/localhost_access_log*.txt

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/view.jsp?display=file:/opt/tomcat/webapps/dbwr/LCPC/CompressorLocal.bob HTTP/1.1" 200 6255

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/widgets/actionbutton.css?V=1786090605 HTTP/1.1" 200 688

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/css/widgets.css?V=1786090605 HTTP/1.1" 200 2595

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/widgets/databrowser.css?V=1786090605 HTTP/1.1" 200 140

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/widgets/boolbutton.css?V=1786090605 HTTP/1.1" 200 101

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/widgets/tabs.css?V=1786090605 HTTP/1.1" 200 1087

10.20.61.51 - - [07/Aug/2026:13:46:45 +0530] "GET /dbwr/widgets/navtabs.css?V=1786090605 HTTP/1.1" 200 1304

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/tank.css?V=1786090605 HTTP/1.1" 200 250

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/textupdate.css?V=1786090605 HTTP/1.1" 200 127

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/group.css?V=1786090605 HTTP/1.1" 200 130

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/led.css?V=1786090605 HTTP/1.1" 200 161

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/textentry.css?V=1786090605 HTTP/1.1" 200 147

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/combo.css?V=1786090605 HTTP/1.1" 200 35

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /pvws/js/pvws.js?V=1786090605 HTTP/1.1" 200 5486

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/scrollbar.js?V=1786090605 HTTP/1.1" 200 1152

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/js/dbwr.js?V=1786090605 HTTP/1.1" 200 22169

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/clock.js?V=1786090605 HTTP/1.1" 200 901

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/xyplot.js?V=1786090605 HTTP/1.1" 200 6185

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/symbol.js?V=1786090605 HTTP/1.1" 200 1065

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/bytemonitor.js?V=1786090605 HTTP/1.1" 200 1361

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/actionbutton.js?V=1786090605 HTTP/1.1" 200 3596

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/databrowser.js?V=1786090605 HTTP/1.1" 200 6373

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/boolbutton.js?V=1786090605 HTTP/1.1" 200 933

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/navtabs.js?V=1786090605 HTTP/1.1" 200 3356

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/tabs.js?V=1786090605 HTTP/1.1" 200 1783

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/led.js?V=1786090605 HTTP/1.1" 200 2963

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/checkbox.js?V=1786090605 HTTP/1.1" 200 1090

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/radio.js?V=1786090605 HTTP/1.1" 200 2473

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/tank.js?V=1786090605 HTTP/1.1" 200 821

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/textupdate.js?V=1786090605 HTTP/1.1" 200 4970

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/slider.js?V=1786090605 HTTP/1.1" 200 999

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/combo.js?V=1786090605 HTTP/1.1" 200 1779

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/textentry.js?V=1786090605 HTTP/1.1" 200 2940

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/picture.js?V=1786090605 HTTP/1.1" 200 755

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/spinner.js?V=1786090605 HTTP/1.1" 200 484

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/image.js?V=1786090605 HTTP/1.1" 200 18304

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/progressbar.js?V=1786090605 HTTP/1.1" 200 541

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/boolmonitor.js?V=1786090605 HTTP/1.1" 200 829

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/multistatemonitor.js?V=1786090605 HTTP/1.1" 200 258

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/widgets/polyline.js?V=1786090605 HTTP/1.1" 200 209

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /dbwr/screen?display=file%3A%2Fopt%2Ftomcat%2Fwebapps%2Fdbwr%2FLCPC%2FCompressorLocal.bob¯os=%7B%7D&cache=true HTTP/1.1" 200 47376

10.20.61.51 - - [07/Aug/2026:13:46:46 +0530] "GET /pvws/pv HTTP/1.1" 101 -

10.20.1.222 - - [07/Aug/2026:13:59:20 +0530] "GET /pvws/pv HTTP/1.1" 101 -

Could you please advise how this issue can be resolved? Specifically, I would appreciate your guidance on

How to configure DBWR to access image/symbol file used in the .bob.

Your guidance on the recommended configuration would be highly appreciated.

With regards

Vishnu

PVA Gateway performance with large image arrays

lvhh--- via Tech-talk — Fri, 07 Aug 2026 13:03:12 GMT

Subject:	PVA Gateway performance with large image arrays
From:	lvhh--- via Tech-talk <tech-talk at aps.anl.gov>
To:	tech-talk <tech-talk at aps.anl.gov>
Date:	Fri, 7 Aug 2026 21:03:12 +0800

Hi all,

We are seeing image update delays when using a PVA Gateway.

p4p Gateway 4.2.2 running in a virtual machine
PyDM on the OPI
Image PV type: LONG/32 bits
Only one image display is active

Each update contains:

1440 × 1024 + 500 × 500 pixels = 6.9MB

At 2 Hz, the image display is smooth. At 10 Hz, it becomes jerky and appears to skip updates.

The OPI works smoothly at 10 Hz when connected directly to the IOC. The problem only occurs through the Gateway.

Has anyone seen a similar issue with large arrays through the p4p Gateway?

Best regards,

Huihui

lvhh at sari.ac.cn

Re: Display Images on .bob using DBWR

Kasemir, Kay via Tech-talk — Fri, 07 Aug 2026 13:04:11 GMT

Subject:	Re: Display Images on .bob using DBWR
From:	"Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>
To:	Vishnu Patel <patel.vishnu at hotmail.com>, EPICS Tech Talk <tech-talk at aps.anl.gov>
Date:	Fri, 7 Aug 2026 13:04:11 +0000

See https://github.com/ornl-epics/dbwr/blob/main/Readme.md and follow the suggestion under “Client URLs” about making all files available via web links.

Instead of

...view.jsp?display=file:/path/to/display.bob

you want to go with

...view.jsp?display=http://my_control_system_host/displays/path/to/display.bob

That way, you’ll end up with image links like

http:/my_control_system_host/LCPC/Symbol/VR Steam Trap.png

that allow the client to fetch the file and not

file:/opt/tomcat/webapps/dbwr/LCPC/Symbol/VR Steam Trap.png

where the client tries to get a file that only exists on the web server file system

From: Tech-talk on behalf of Vishnu Patel via Tech-talk
Date: Friday, August 7, 2026 at 5:49 AM
To: EPICS Tech Talk
Subject: [EXTERNAL] Display Images on .bob using DBWR

This Message Is From an External Sender

This email was sent from a non-ORNL address. If suspicious, use the Report Phish button in Outlook.