http://blogs.law.harvard.edu/tech/rss EPICS Tech-talk mailing list https://epics.anl.gov/tech-talk/index.php Email archive for the EPICS Tech-talk mailing list. anj@aps.anl.gov https://epics.anl.gov/icons/logoOnly.png EPICS Tech-talk mailing list https://epics.anl.gov/tech-talk/index.php Wed, 10 Jun 2026 20:16:14 GMT https://epics.anl.gov/tech-talk/2026/msg00661.php Michael Davidsaver via Tech-talk Tue, 09 Jun 2026 00:29:04 GMT 20a9a4dc-d0d5-457d-bc32-113fe6490c9b@gmail.com Re: PVA OUT Links in EPICS:
Subject: Re: PVA OUT Links in EPICS:
From: Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
To: Varuna Crishan Meddage <vmeddage at fnal.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Mon, 8 Jun 2026 17:29:04 -0700
On 6/8/26 4:13 PM, Varuna Crishan Meddage via Tech-talk wrote:

I have an analog output record which outputs to another analog output record (published by different IOC) as defined below

================================================================================

record(ao, "PIP2:CTRL_MPS:4:AO:SLOW_SET:CH:1") {
    field(OUT, {pva:{"pv":"acq2106_345:4:AO:SLOW_SET:CH:1"}})
}
...
Is it possible to get rid of this invalid severity even before writing a value to this PV ?

I tried different tricks for example setting field(VAL, "0") and field(PINI, "YES"), but none of them was successful.

For me, initializing VAL to 0 does clear the severity.  Although if you are looking at "dbpr" output, it is necessary to look closely as this "trick" does _not_ zero STAT.  Which is ok, as STAT field only has meaning if SEVR!=0.


Loading the database shown above.


epics> dbpr PIP2:CTRL_MPS:4:AO:SLOW_SET:CH:1  
AMSG:               ASG :               DESC:               DISA: 0              
DISV: 1             NAME: PIP2:CTRL_MPS:4:AO:SLOW_SET:CH:1  NAMSG:               
OMOD: 0             OVAL: 0             RBV : 0             RVAL: 0              
SEVR: INVALID       STAT: UDF           TPRO: 0             VAL : 0             


Loading the following:

record(ao, "PIP2:CTRL_MPS:4:AO:SLOW_SET:CH:1") {
   field(OUT, {pva:{"pv":"acq2106_345:4:AO:SLOW_SET:CH:1"}})
   field(VAL, "0.0")
}
I then see:


epics> dbpr PIP2:CTRL_MPS:4:AO:SLOW_SET:CH:1  
AMSG:               ASG :               DESC:               DISA: 0              
DISV: 1             NAME: PIP2:CTRL_MPS:4:AO:SLOW_SET:CH:1  NAMSG:               
OMOD: 0             OVAL: 0             RBV : 0             RVAL: 0              
SEVR: NO_ALARM      STAT: UDF           TPRO: 0             VAL : 0             

Note the different values of SEVR.


]]> https://epics.anl.gov/tech-talk/2026/msg00662.php Michael Davidsaver via Tech-talk Tue, 09 Jun 2026 00:36:19 GMT 752d2d4b-8e38-425a-b96a-eb6fec07897b@gmail.com Re: PVA OUT Links in EPICS:
Subject: Re: PVA OUT Links in EPICS:
From: Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
To: Varuna Crishan Meddage <vmeddage at fnal.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Mon, 8 Jun 2026 17:36:19 -0700
On 6/8/26 4:13 PM, Varuna Crishan Meddage via Tech-talk wrote:
I tried different tricks for example setting field(VAL, "0") and field(PINI, "YES"), but none of them was successful.

I should also note that setting PINI to YES will leave this record with a INVALID LINK alarm as the PVA link is unlikely to be connected by the time of the initial process scan.

Depending on your desired reconnect behavior, you may wish to investigate the "retry" link option.

retry. For an output link, and true (not default), then the most recent incomplete PUT will be re-tried when the target PV (re)connects.

https://epics-base.github.io/pvxs/pvalink.html


]]> https://epics.anl.gov/tech-talk/2026/msg00663.php Gofron, Kaz via Tech-talk Tue, 09 Jun 2026 02:26:48 GMT CO6PR09MB7334B04236DD37185C93D67DA91D2@CO6PR09MB7334.namprd09.prod.outlook.com Phoebus 4.7 — `lsi`/`lso` long strings, `.$` PV names, and macro “not fully resolved” warnings
Subject: Phoebus 4.7 — `lsi`/`lso` long strings, `.$` PV names, and macro “not fully resolved” warnings
From: "Gofron, Kaz via Tech-talk" <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc: "kgofron at comcast.net" <kgofron at comcast.net>, "Gofron, Kaz" <gofronkj at ornl.gov>
Date: Tue, 9 Jun 2026 02:26:48 +0000
# EPICS Phoebus 4.7 and `lsi`/`lso` `.$` PV names

**Subject:** Phoebus 4.7 — `lsi`/`lso` long strings, `.$` PV names, and macro “not fully resolved” warnings

---

Hello,

I am wiring a PyDevice IOC for TAS scan plotting (Phoebus OPI + `lsi`/`lso` path PVs) and hit a mismatch between **EPICS long-string CA access** and **Phoebus Display Builder macro resolution** in Phoebus **4.7.4-SNAPSHOT**. I would like to confirm the recommended pattern for **editable** full file paths in Phoebus.

## EPICS / CA side (works as documented)

For `lsi`/`lso` with `SIZV` > 40:

- Plain `caget TAS:Plot:SelectedFile` returns only the first **40 characters** (`DBR_STRING`).
- Full path works with the long-string modifier, e.g.
`caget -S TAS:Plot:SelectedFile.$`
or `caget -S TAS:Plot:SelectedFile.VAL$`.

Phoebus widgets need **`format=String`** (format 6) on textentry/textupdate. That part is clear from prior tech-talk threads and SNS training material.

## Phoebus 4.7 issue: `.$` in `pv_name`

Binding the OPI to `$(P)SelectedFile.$` (or `FullFileName_RBV.$`, `ColHeaders_RBV.$`, etc.) **works at runtime** after the display connects — full paths display, FileSelector browse loads data, plot updates.

On **every screen reload**, however, the Phoebus terminal logs warnings such as:

```
Widget 'SelectedFile' (textentry) 'pv_name' is not fully resolved: 'TAS:Plot:SelectedFile.$'
Widget 'GraphData' ... pv0 '$(P)ColHeaders_RBV.$' is not fully resolved: TAS:Plot:ColHeaders_RBV.$
```

Widgets can show a **magenta border** until a PV connects; the border often clears after browse/select.

I traced this to Phoebus macro handling: after `$(P)` expands, the resolved name still contains a literal `$`. `MacroHandler.containsMacros()` treats **any** `$` as an unresolved macro (`indexOf('$') >= 0`). So `TAS:Plot:SelectedFile.$` is flagged even though it is a valid EPICS channel name, not a Phoebus macro.

## Workarounds we tried

| Approach | Result |
|----------|--------|
| `$(P)SelectedFile.$` with `format=String` | Works at runtime; load warnings remain |
| `ca://$(P)SelectedFile.VAL$` | Same — still contains `$` |
| Display macro `LONGSTR=.$` → `$(P)SelectedFile$(LONGSTR)` | **Fails** — macro value `.$` triggers `Incomplete macro expansion LONGSTR='.$'` |
| `{"longString":true}` modifier | Avoids `$` in the name, but default `pv_name_patches` strips it; unclear if that restores full-length CA reads for `lso` |

## Current workaround: CHAR waveform PVs (pcaspy style)

We followed the **pcaspy** / `plotData.bob` pattern: `waveform` with `FTVL=CHAR`, Phoebus `pv_name` without `$`, `format=String`:

- `SelectedFilePath`, `FullFileNameText`, `ColHeadersText`, `CommandText`, `DataFileText`

This **removes all Phoebus load warnings** and readback/display work well.

**Open problem:** `SelectedFilePath` is **not yet writable from the Phoebus File textentry** (browse via FileSelector and plot reload otherwise work). We use PyDevice `INP` with `('VAL', 'TPRO')` on the waveform record; Python `set_selected_file()` runs in unit tests but screen writes do not reach the IOC the same way `lso` `OUT` does.

Legacy `lso SelectedFile` + `caput -S ….$` still works from the shell.

## Questions for the community

1. What is the **supported Phoebus 4.7** `pv_name` for an **editable** `lso`/`lsi` path field (full read/write, no load warnings)?
2. Are the `not fully resolved` warnings for `.$` **expected/harmless**, or is there a preferred syntax (site preference, escape sequence, `ca://` variant) we missed?
3. For **PyDevice** (or soft IOC) paths, is **writable CHAR waveform** the recommended substitute for `lso`, or is there a better record/link pattern for Phoebus writes?
4. Has this improved in Phoebus **5.x** or newer Jackie/PV layers?

Environment: EPICS base 7.x, PyDevice IOC, Phoebus 4.7.4-SNAPSHOT, Channel Access (no PVAccess on this IOC yet). Example path length ~90 characters; `SIZV=255`.

Thanks for any pointers to documented practice or OPI examples that handle long `lso` paths without `$` in the Display Builder `pv_name`.

Best regards,
Kazimierz Gofron

P.S. Phoebus messages

```
WARNING [org.csstudio.display.builder.model] Widget 'SelectedFile' (textentry) 'pv_name' is not fully resolved: 'TAS:Plot:SelectedFile.$'
WARNING [org.csstudio.display.builder.model] Widget 'SelectedFile' (textentry) 'tooltip' is not fully resolved: 'Full path; browse, paste, or edit (lso SelectedFile.$)'
WARNING [org.csstudio.display.builder.model] Widget 'FileSelector' (fileselector) 'tooltip' is not fully resolved: 'Browse for scan file (writes SelectedFile.$)'
WARNING [org.csstudio.display.builder.model] Widget 'FullFileName' (textupdate) 'pv_name' is not fully resolved: 'TAS:Plot:FullFileName_RBV.$'
```
]]> https://epics.anl.gov/tech-talk/2026/msg00664.php Wang, Lin via Tech-talk Tue, 09 Jun 2026 07:08:32 GMT 76ca6b67.45f3e.19eab362388.Coremail.wanglin@ihep.ac.cn Wrapper of pyepics and p4p
Subject: Wrapper of pyepics and p4p
From: "Wang, Lin via Tech-talk" <tech-talk at aps.anl.gov>
To: tech-talk at aps.anl.gov
Date: Tue, 9 Jun 2026 15:08:32 +0800 (GMT+08:00)

Dear all,


A wrapper of pyepics and p4p has been developed and shared in the following links,


https://github.com/wanglin86769/capva

https://pypi.org/project/capva


It is developed based on the epicsWS module of weiss [1] project and the EPICS client layer is extracted as a standalone PV client library. Single API for both CA and PVA is provided, and the data format for PV get and monitor operations is a unified PVData model, which is carried over directly from the weiss project.


For more detail, please refer to the GitHub link above.



Regards,

Lin



[1] https://github.com/weiss-controls/weiss


]]> https://epics.anl.gov/tech-talk/2026/msg00665.php Ralph Lange via Tech-talk Tue, 09 Jun 2026 07:16:25 GMT CAGJXJ2Humt06_F4b+a-svYHrf_Pg1eteL+3huQixsOEtAByyQw@mail.gmail.com Re: PVA OUT Links in EPICS:
Subject: Re: PVA OUT Links in EPICS:
From: Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 09:16:25 +0200
On Tue, 9 Jun 2026 at 01:14, Varuna Crishan Meddage via Tech-talk <tech-talk at aps.anl.gov> wrote:

Is it possible to get rid of this invalid severity even before writing a value to this PV ?

All EPICS records have the field UDFS (undefined alarm severity) that configures the severity the record should have when it is undefined.

Cheers,
~Ralph


]]> https://epics.anl.gov/tech-talk/2026/msg00666.php André Favoto via Tech-talk Tue, 09 Jun 2026 07:35:46 GMT PH0PR02MB7527B7923BEEAA779F781305D11D2@PH0PR02MB7527.namprd02.prod.outlook.com Re: Wrapper of pyepics and p4p
Subject: Re: Wrapper of pyepics and p4p
From: André Favoto via Tech-talk <tech-talk at aps.anl.gov>
To: "Wang, Lin" <wanglin at ihep.ac.cn>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 07:35:46 +0000
Hi!
Coincidently or not, on the previous thread I was just talking about this. 
As epicsWS is already fully decoupled from WEISS frontend, I would be willing to make it a separate standalone module inside the organization, and just submodule it in the core project. This way, WEISS (and everyone else) could also benefit from improvements and effort you put into it.
I think it would be of better use for the community if we joined forces instead of maintaining separate projects for the same purpose

I'll reach out so we can talk a bit more about that :) 
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Wang, Lin via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, 09 June 2026 09:08:32
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Wrapper of pyepics and p4p
 

Dear all,


A wrapper of pyepics and p4p has been developed and shared in the following links,


https://github.com/wanglin86769/capva

https://pypi.org/project/capva


It is developed based on the epicsWS module of weiss [1] project and the EPICS client layer is extracted as a standalone PV client library. Single API for both CA and PVA is provided, and the data format for PV get and monitor operations is a unified PVData model, which is carried over directly from the weiss project.


For more detail, please refer to the GitHub link above.



Regards,

Lin



[1] https://github.com/weiss-controls/weiss


]]> https://epics.anl.gov/tech-talk/2026/msg00667.php Varuna Crishan Meddage via Tech-talk Tue, 09 Jun 2026 13:29:48 GMT DS0PR09MB11428CF4FBC0AD598A01FBA41B21D2@DS0PR09MB11428.namprd09.prod.outlook.com Re: PVA OUT Links in EPICS:
Subject: Re: PVA OUT Links in EPICS:
From: Varuna Crishan Meddage via Tech-talk <tech-talk at aps.anl.gov>
To: Michael Davidsaver <mdavidsaver at gmail.com>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 13:29:48 +0000
Thank you.
From: Michael Davidsaver <mdavidsaver at gmail.com>
Sent: Monday, June 8, 2026 7:36 PM
To: Varuna Crishan Meddage <vmeddage at fnal.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PVA OUT Links in EPICS:
 

[EXTERNAL] – This message is from an external sender

On 6/8/26 4:13 PM, Varuna Crishan Meddage via Tech-talk wrote:
I tried different tricks for example setting field(VAL, "0") and field(PINI, "YES"), but none of them was successful.

I should also note that setting PINI to YES will leave this record with a INVALID LINK alarm as the PVA link is unlikely to be connected by the time of the initial process scan.

Depending on your desired reconnect behavior, you may wish to investigate the "retry" link option.

retry. For an output link, and true (not default), then the most recent incomplete PUT will be re-tried when the target PV (re)connects.

https://epics-base.github.io/pvxs/pvalink.html


]]> https://epics.anl.gov/tech-talk/2026/msg00668.php Marks, Nicholas via Tech-talk Tue, 09 Jun 2026 15:10:13 GMT SA7PR09MB121705911DDA98366D9C8ACD6C11D2@SA7PR09MB12170.namprd09.prod.outlook.com Re: CA Provider for PVXS
Subject: Re: CA Provider for PVXS
From: "Marks, Nicholas via Tech-talk" <tech-talk at aps.anl.gov>
To: André Favoto <andrefavotto at outlook.com>, Michael Davidsaver <mdavidsaver at gmail.com>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 15:10:13 +0000
Thanks everyone for the helpful notes! Good we have a tech-talk thread about this now as I imagine it will continue to be a common question for newcomers writing clients. I tried mocking up a simple client and I'd agree the one library per protocol approach seems to work well. For a simple client along the lines of what Kay mentioned (just needing a “PV” with value, timestamp, etc) using both CA and PVXS together only takes a couple hundred lines of code per protocol, so this is probably the simplest approach.
Take care,
Nick
From: André Favoto <andrefavotto at outlook.com>
Sent: Monday, June 8, 2026 3:08 PM
To: Marks, Nicholas <nmarks at anl.gov>; Michael Davidsaver <mdavidsaver at gmail.com>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: CA Provider for PVXS
 
You don't often get email from andrefavotto at outlook.com. Learn why this is important
I went though this exact same chain of thought when starting WEISS ~1 year ago, and I believe most people starting new clients also do. To share a bit of my endeavor: I started by using pvaPy, as it does support PVA and CA within the same library. 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd
I went though this exact same chain of thought when starting WEISS ~1 year ago, and I believe most people starting new clients also do. To share a bit of my endeavor:

I started by using pvaPy, as it does support PVA and CA within the same library. However, with the goal of using PVXS, I wanted to use p4p. I opened this issue on p4p due to the existence of the "provider" parameter, which could lead one to believe other providers were to be supported at some point (thanks Michael for the prompt response🙂). As already suggested and I later agreed as the best solution, I ended up migrating to a dual-protocol backend.

I still wanted a transparent interface for the frontend, to simplify the TypeScript data layer. As Kasemir correctly pointed out, most clients don't need all the details the low-level clients can provide. With that in mind, I created a parser, protocol aware, that always returns the same NT-ish data structure. Parts of it were also based on PVWS, but tailored for WEISS' needs. On the connection management layer, epicsWS, I just call the proper parser method according to the PV provider from which the update came from. I have used this approach for a while now, and can switch seamlessly between CA and PVA. 

FWIW, although those were developed specifically for WEISS backend, the application can be used as a standalone service via the docker container or local build. 

Hope this helps!

Cheers,

André Favoto

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, June 8, 2026 19:25
To: Marks, Nicholas <nmarks at anl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: CA Provider for PVXS
 
Hello Nick,

On 6/8/26 8:35 AM, Marks, Nicholas via Tech-talk wrote:
Hello,

I was curious if there has been any discussion in the community about implementing a Channel Access provider for PVXS? I think most would agree the PVXS API is much easier to work with than the pvAccessCPP API, however one thing pvAccessCPP has over PVXS is it also provides a CA provider(epics::pvAccess::ca::CAClientFactory::start(); pvac::ClientProvider provider("ca");).

I was not enthused about supporting the (imo.) hacky code behind CA ClientProvider.  Wrapping libca adds the problem of API impedance mismatch to the differences between the two protocols.  I do not see a similar wrapper appearing in PVXS.  I would not rule out including a new CA implementation, with a similar API, but this is not at all a priority for me.


Any new client applications will likely need to support both CA and PVA (except maybe for some very new sites which are trying PVA only) so it is especially useful to have a single API for the EPICS communication layer of such an application. The way I see it, a C++ EPICS client which is to support both CA and PVA will need to use PVXS for PVA and the C API for Channel Access or alternatively stick with pvAccessCPP. This isn't the end of the world, but it sure would be nice to use PVXS for both protocols. I'm interested to hear others' thoughts on this.

To my mind, dual protocol servers are the way to go.  I think the server side is better equipped to handle the differences between the two protocols.  Including QSRV2 in all IOCs provides a ~95% solution.


If "transparent" support for PVA/CA is critical for your client application, and "pvac::ClientProvider" + CAProvider works for you, then great.  "pvac::" was my last attempt to wrap a not-horrible API around pvAccessCPP.  Like much of the original pvDataCPP stack, it is in deep maintenance mode at this point.  Still, the EPICS community has a history of keeping such code ~viable for a very long time.  I doubt that obsolescence will force a migration on you anytime soon.


]]> https://epics.anl.gov/tech-talk/2026/msg00669.php Mark Rivers via Tech-talk Tue, 09 Jun 2026 21:46:40 GMT PH3PPF25FF874616811E785907BDF96F5DA991D2@PH3PPF25FF87461.namprd11.prod.outlook.com Strange problem linking a library on windows-x64
Subject: Strange problem linking a library on windows-x64
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 21:46:40 +0000
Folks,

I am having a strange problem linking a library on windows-x64 (dynamic build).  The library compiles and links fine on windows-x64-static (static build).

On windows-x64 the library compiles fine, but generates this error when linking:

link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:ixwebsocket.dll -implib:ixwebsocket.lib     IXBench.obj IXCancellationRequest.obj IXConnectionState.obj IXDNSLookup.obj IXExponentialBackoff.obj IXGzipCodec.obj IXHttpClient.obj IXHttp.obj IXHttpServer.obj IXNetSystem.obj IXSelectInterrupt.obj IXSelectInterruptEvent.obj IXSelectInterruptFactory.obj IXSelectInterruptPipe.obj IXSetThreadName.obj IXSocketAppleSSL.obj IXSocketConnect.obj IXSocket.obj IXSocketFactory.obj IXSocketMbedTLS.obj IXSocketOpenSSL.obj IXSocketServer.obj IXSocketTLSOptions.obj IXStrCaseCompare.obj IXUdpSocket.obj IXUrlParser.obj IXUserAgent.obj IXUuid.obj IXWebSocketCloseConstants.obj IXWebSocket.obj IXWebSocketHandshake.obj IXWebSocketHttpHeaders.obj IXWebSocketPerMessageDeflateCodec.obj IXWebSocketPerMessageDeflate.obj IXWebSocketPerMessageDeflateOptions.obj IXWebSocketProxyServer.obj IXWebSocketServer.obj IXWebSocketTransport.obj        ws2_32.lib crypt32.lib bcrypt.lib
Generating code
Finished generating code
"Installing shared library ../../../../bin/windows-x64/ixwebsocket.dll"
"Installing library ../../../../lib/windows-x64/ixwebsocket.lib"
installEpics.pl: No such file 'ixwebsocket.lib' at H:/epics-devel/base-7.0.10/bin/windows-x64/installEpics.pl line 54.
make[3]: *** [H:/epics-devel/base-7.0.10/configure/RULES_BUILD:489: ../../../../lib/windows-x64/ixwebsocket.lib] Error 2
make[3]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/FX4Src/ixwebsocket/O.windows-x64'
make[2]: *** [H:/epics-devel/base-7.0.10/configure/RULES_ARCHS:58: install.windows-x64] Error 2
make[2]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/FX4Src/ixwebsocket'
make[1]: *** [H:/epics-devel/base-7.0.10/configure/RULES_DIRS:85: FX4Src/ixwebsocket.install] Error 2
make[1]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp'
make: *** [H:/epics-devel/base-7.0.10/configure/RULES_DIRS:85: quadEMApp.install] Error 2

Note that the link command did not generate an error.  However, there is an error when it tries to install the ixwebsocket.lib.  The problem is that the library file is not being created.

If I cd to the O.windows-x64 directory and manually type the "link" command it completes with no errors:

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:ixwebsocket.dll -implib:ixwebsocket.lib     IXBench.obj IXCancellationRequest.obj IXConnectionState.obj IXDNSLookup.obj IXExponentialBackoff.obj IXGzipCodec.obj IXHttpClient.obj IXHttp.obj IXHttpServer.obj IXNetSystem.obj IXSelectInterrupt.obj IXSelectInterruptEvent.obj IXSelectInterruptFactory.obj IXSelectInterruptPipe.obj IXSetThreadName.obj IXSocketAppleSSL.obj IXSocketConnect.obj IXSocket.obj IXSocketFactory.obj IXSocketMbedTLS.obj IXSocketOpenSSL.obj IXSocketServer.obj IXSocketTLSOptions.obj IXStrCaseCompare.obj IXUdpSocket.obj IXUrlParser.obj IXUserAgent.obj IXUuid.obj IXWebSocketCloseConstants.obj IXWebSocket.obj IXWebSocketHandshake.obj IXWebSocketHttpHeaders.obj IXWebSocketPerMessageDeflateCodec.obj IXWebSocketPerMessageDeflate.obj IXWebSocketPerMessageDeflateOptions.obj IXWebSocketProxyServer.obj IXWebSocketServer.obj IXWebSocketTransport.obj        ws2_32.lib crypt32.lib bcrypt.lib
Generating code
Finished generating code

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>

It should have created ixwebsocket.dll and ixwebsocket.lib.  However, when I look for those files in the O.windows-x64 directory only the .dll file exists, not the .lib file:

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>dir *.lib *.dll
 Volume in drive J is people_rw
 Volume Serial Number is 5005-CD09

 Directory of J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64


 Directory of J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64

06/09/2026  04:37 PM           284,672 ixwebsocket.dll
               1 File(s)        284,672 bytes
               0 Dir(s)  9,569,302,556,672 bytes free


I have never seen this problem before.  Any idea what could cause it?

Thanks,
Mark



]]> https://epics.anl.gov/tech-talk/2026/msg00670.php Lewis, Laura via Tech-talk Tue, 09 Jun 2026 22:19:44 GMT SA1PR07MB974236BDB5BA5464C38C4EDCF41D2@SA1PR07MB9742.namprd07.prod.outlook.com pvua: Another wrapper of pyepics and p4p
Subject: pvua: Another wrapper of pyepics and p4p
From: "Lewis, Laura via Tech-talk" <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 22:19:44 +0000
Dear all,

At SLAC we created a small Python library called pvua (PV Unified Access), which wraps pyepics and p4p. It is intended to support transitioning older programs to use pvAccess by providing a close approximation of the pyepics library's functions and classes. It is similar to the solutions listed in prior threads, but the API is designed around supporting applications that expect to be using pyepics (hence, CA), so it is particularly well suited for updating legacy software to use pvAccess without necessitating a larger rework. The library seems to be working fairly well for our use cases, albeit with extremely minor overhead paid by not interfacing with CA/PVA directly.

This software was written for Python environments, which is why we did not use C++ or look for existing C++ solutions.

Hosted at https://github.com/slac-epics/pvua.

Regards,
Laura
]]> https://epics.anl.gov/tech-talk/2026/msg00671.php J. Lewis Muir via Tech-talk Tue, 09 Jun 2026 22:34:32 GMT aiiT7hZQPzE6ilqx@mail.imca-cat.org Re: Strange problem linking a library on windows-x64
Subject: Re: Strange problem linking a library on windows-x64
From: "J. Lewis Muir via Tech-talk" <tech-talk at aps.anl.gov>
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 17:34:32 -0500 
On 06/09, Mark Rivers via Tech-talk wrote:
> I have never seen this problem before.  Any idea what could cause it?

Hi, Mark!

Are you running make with the number of jobs set to more than 1?  Maybe
try "-j1" to rule out a parallel make race?

Lewis
]]> https://epics.anl.gov/tech-talk/2026/msg00672.php Mark Rivers via Tech-talk Tue, 09 Jun 2026 22:54:47 GMT PH3PPF25FF87461A848823045F9B59CA16C991D2@PH3PPF25FF87461.namprd11.prod.outlook.com Re: Strange problem linking a library on windows-x64
Subject: Re: Strange problem linking a library on windows-x64
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: "J. Lewis Muir" <jlmuir at imca-cat.org>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Tue, 9 Jun 2026 22:54:47 +0000
Hi Lewis,

I showed that the problem has nothing to do with "make".  When I manually typed the "link" command it produced ixwebsocket.dll, but failed to produce ixwebsocket.lib.

Mark

From: J. Lewis Muir <jlmuir at imca-cat.org>
Sent: Tuesday, June 9, 2026 5:34 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Strange problem linking a library on windows-x64
 
On 06/09, Mark Rivers via Tech-talk wrote:
> I have never seen this problem before.  Any idea what could cause it?

Hi, Mark!

Are you running make with the number of jobs set to more than 1?  Maybe
try "-j1" to rule out a parallel make race?

Lewis
]]> https://epics.anl.gov/tech-talk/2026/msg00673.php Freddie Akeroyd - STFC UKRI via Tech-talk Wed, 10 Jun 2026 00:31:49 GMT LO0P265MB48321B0E463558AE80488A17D81A2@LO0P265MB4832.GBRP265.PROD.OUTLOOK.COM RE: Strange problem linking a library on windows-x64
Subject: RE: Strange problem linking a library on windows-x64
From: Freddie Akeroyd - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 00:31:49 +0000

Hi Mark,

 

In a dynamic build ixwebsocket.lib is the import library containing the exported symbol references from the DLL, if the DLL has no symbols exported then I believe link will not create an import library. You can confirm whether the DLL exports any symbols by running

 

    dumpbin  /exports ixwebsocket.dll

 

To resolve this check the header files for the library, there may be some additional preprocessor symbol that needs defining during an EPICS dynamic build so that the library source adds     __declspec(dllexport)   to relevant functions to  create an import library.     

 

Regards,

 

Freddie

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: 09 June 2026 22:47
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Strange problem linking a library on windows-x64

 

Folks,

 

I am having a strange problem linking a library on windows-x64 (dynamic build).  The library compiles and links fine on windows-x64-static (static build).

 

On windows-x64 the library compiles fine, but generates this error when linking:

 

link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:ixwebsocket.dll -implib:ixwebsocket.lib     IXBench.obj IXCancellationRequest.obj IXConnectionState.obj IXDNSLookup.obj IXExponentialBackoff.obj IXGzipCodec.obj IXHttpClient.obj IXHttp.obj IXHttpServer.obj IXNetSystem.obj IXSelectInterrupt.obj IXSelectInterruptEvent.obj IXSelectInterruptFactory.obj IXSelectInterruptPipe.obj IXSetThreadName.obj IXSocketAppleSSL.obj IXSocketConnect.obj IXSocket.obj IXSocketFactory.obj IXSocketMbedTLS.obj IXSocketOpenSSL.obj IXSocketServer.obj IXSocketTLSOptions.obj IXStrCaseCompare.obj IXUdpSocket.obj IXUrlParser.obj IXUserAgent.obj IXUuid.obj IXWebSocketCloseConstants.obj IXWebSocket.obj IXWebSocketHandshake.obj IXWebSocketHttpHeaders.obj IXWebSocketPerMessageDeflateCodec.obj IXWebSocketPerMessageDeflate.obj IXWebSocketPerMessageDeflateOptions.obj IXWebSocketProxyServer.obj IXWebSocketServer.obj IXWebSocketTransport.obj        ws2_32.lib crypt32.lib bcrypt.lib

Generating code

Finished generating code

"Installing shared library ../../../../bin/windows-x64/ixwebsocket.dll"

"Installing library ../../../../lib/windows-x64/ixwebsocket.lib"

installEpics.pl: No such file 'ixwebsocket.lib' at H:/epics-devel/base-7.0.10/bin/windows-x64/installEpics.pl line 54.

make[3]: *** [H:/epics-devel/base-7.0.10/configure/RULES_BUILD:489: ../../../../lib/windows-x64/ixwebsocket.lib] Error 2

make[3]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/FX4Src/ixwebsocket/O.windows-x64'

make[2]: *** [H:/epics-devel/base-7.0.10/configure/RULES_ARCHS:58: install.windows-x64] Error 2

make[2]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/FX4Src/ixwebsocket'

make[1]: *** [H:/epics-devel/base-7.0.10/configure/RULES_DIRS:85: FX4Src/ixwebsocket.install] Error 2

make[1]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp'

make: *** [H:/epics-devel/base-7.0.10/configure/RULES_DIRS:85: quadEMApp.install] Error 2

 

Note that the link command did not generate an error.  However, there is an error when it tries to install the ixwebsocket.lib.  The problem is that the library file is not being created.

 

If I cd to the O.windows-x64 directory and manually type the "link" command it completes with no errors:

 

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:ixwebsocket.dll -implib:ixwebsocket.lib     IXBench.obj IXCancellationRequest.obj IXConnectionState.obj IXDNSLookup.obj IXExponentialBackoff.obj IXGzipCodec.obj IXHttpClient.obj IXHttp.obj IXHttpServer.obj IXNetSystem.obj IXSelectInterrupt.obj IXSelectInterruptEvent.obj IXSelectInterruptFactory.obj IXSelectInterruptPipe.obj IXSetThreadName.obj IXSocketAppleSSL.obj IXSocketConnect.obj IXSocket.obj IXSocketFactory.obj IXSocketMbedTLS.obj IXSocketOpenSSL.obj IXSocketServer.obj IXSocketTLSOptions.obj IXStrCaseCompare.obj IXUdpSocket.obj IXUrlParser.obj IXUserAgent.obj IXUuid.obj IXWebSocketCloseConstants.obj IXWebSocket.obj IXWebSocketHandshake.obj IXWebSocketHttpHeaders.obj IXWebSocketPerMessageDeflateCodec.obj IXWebSocketPerMessageDeflate.obj IXWebSocketPerMessageDeflateOptions.obj IXWebSocketProxyServer.obj IXWebSocketServer.obj IXWebSocketTransport.obj        ws2_32.lib crypt32.lib bcrypt.lib

Generating code

Finished generating code

 

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>

 

It should have created ixwebsocket.dll and ixwebsocket.lib.  However, when I look for those files in the O.windows-x64 directory only the .dll file exists, not the .lib file:

 

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>dir *.lib *.dll

 Volume in drive J is people_rw

 Volume Serial Number is 5005-CD09

 

 Directory of J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64

 

 

 Directory of J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64

 

06/09/2026  04:37 PM           284,672 ixwebsocket.dll

               1 File(s)        284,672 bytes

               0 Dir(s)  9,569,302,556,672 bytes free

 

 

I have never seen this problem before.  Any idea what could cause it?

 

Thanks,

Mark

 

 

 

]]> https://epics.anl.gov/tech-talk/2026/msg00674.php Dmitry Yu. Bolkhovityanov via Tech-talk Wed, 10 Jun 2026 05:10:03 GMT aa1eda0-18f4-2e29-d275-4672925bf5a7@starnew.inp.nsk.su Re: CA Provider for PVXS
Subject: Re: CA Provider for PVXS
From: "Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk at aps.anl.gov>
To: "Kasemir, Kay" <kasemirk at ornl.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 12:10:03 +0700 (+07) 
Hi Kay,

On Mon, 8 Jun 2026, Kasemir, Kay via Tech-talk wrote:


The hard part is of course that you can never get 2 people to agree on what such a ?PV?, the common denominator of all protocols, should look like.


Is there really much disagreement?

A "PV" usually consists of:

1. The data itself (with type descriptor - int/float/..., # of elements).
2. A timestamp.
3. A "status" of some kind (STAT+SEVR, quality, a bitmask of errors, ...).
Or are you talking about API? That is usually "read, write, monitor". Even TANGO, with its messy DeviceAttribute (whose internals violate most "good design practices") is compatible (and pairable) with EPICS. 


With best regards,
Dmitry
]]> https://epics.anl.gov/tech-talk/2026/msg00675.php André Favoto via Tech-talk Wed, 10 Jun 2026 08:40:41 GMT PH0PR02MB7527D6C37D6AE11D5710D949D11A2@PH0PR02MB7527.namprd02.prod.outlook.com Re: CA Provider for PVXS
Subject: Re: CA Provider for PVXS
From: André Favoto via Tech-talk <tech-talk at aps.anl.gov>
To: "Kasemir, Kay" <kasemirk at ornl.gov>, "Dmitry Yu. Bolkhovityanov" <D.Yu.Bolkhovityanov at inp.nsk.su>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 08:40:41 +0000
I think the disagreement is not on what should be forwarded, but on how it should be presented.
From the data perspective, all of them usually provide what you mentioned (value, timestamp, type, units, etc), content-wise, but with slightly different formats depending on how one thinks data consumption gets easier.
A clear example already showed up in the prior emails:
The first two include only CA and PVA. For the cases like PVWS or the Java clients, that may support MQTT/Tango/others, it may get even harder to agree on "one standard to rule them all", despite the contents being kind of the same.


Cheers,
André Favoto

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Dmitry Yu. Bolkhovityanov via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, June 10, 2026 07:10
To: Kasemir, Kay <kasemirk at ornl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: CA Provider for PVXS
 
Hi Kay,

On Mon, 8 Jun 2026, Kasemir, Kay via Tech-talk wrote:

> The hard part is of course that you can never get 2 people to agree on what such a ?PV?, the common denominator of all protocols, should look like.

Is there really much disagreement?

A "PV" usually consists of:

1. The data itself (with type descriptor - int/float/..., # of elements).
2. A timestamp.
3. A "status" of some kind (STAT+SEVR, quality, a bitmask of errors, ...).

Or are you talking about API?  That is usually "read, write, monitor".
Even TANGO, with its messy DeviceAttribute (whose internals violate most
"good design practices") is compatible (and pairable) with EPICS.


With best regards,
Dmitry
]]> https://epics.anl.gov/tech-talk/2026/msg00676.php Rea Domitrović via Tech-talk Wed, 10 Jun 2026 10:52:53 GMT 3fa52b2ce3cb49268feb45f098f22059@irb.hr EPICS support for Fastech motors
Subject: EPICS support for Fastech motors
From: Rea Domitrović via Tech-talk <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 10:52:53 +0000

Hi all,


I'm working with some Fastech Ezi-Servo II Plus-E motors, and I was wondering if someone had already worked with them and/or made an EPICS driver or Motor submodule? This particular line of motors and drives uses an Ethernet interface. Kind regards,


Rea Domitrović

Institut Ruđer Bošković

Zagreb, Croatia

]]> https://epics.anl.gov/tech-talk/2026/msg00677.php Torsten Bögershausen via Tech-talk Wed, 10 Jun 2026 11:49:41 GMT 87cf4b86-3e74-4fe4-abb2-15ad34623f8c@edom.se Re: EPICS support for Fastech motors
Subject: Re: EPICS support for Fastech motors
From: Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>
To: Rea Domitrović <rea.domitrovic at irb.hr>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 13:49:41 +0200 
Hej Rea,

I haven't worked with them, no.
If you have Ethernet (not to be confused with EtherCAT),
I read the manual as if they use UDP for communication,
and knowing that you can write a simple model 3 driver, I think.
(Other suggestions are welcome of course)
/Torsten


On 2026-06-10 12:52, Rea Domitrović via Tech-talk wrote:

Hi all,
I'm working with some Fastech Ezi-Servo II Plus-E motors, and I was wondering if someone had already worked with them and/or made an EPICS driver or Motor submodule? This particular line of motors and drives uses an Ethernet interface. Kind regards, 


Rea Domitrović

Institut Ruđer Bošković

Zagreb, Croatia
]]> https://epics.anl.gov/tech-talk/2026/msg00678.php Mark Rivers via Tech-talk Wed, 10 Jun 2026 14:21:33 GMT DM3PPF1CEB6B7EFB4D4428701C31C3C1991991A2@DM3PPF1CEB6B7EF.namprd11.prod.outlook.com Re: Strange problem linking a library on windows-x64
Subject: Re: Strange problem linking a library on windows-x64
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>, Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk>
Date: Wed, 10 Jun 2026 14:21:33 +0000
Hi Freddie,

Thanks for the hint, that was indeed the problem.  I am building the IXWebSocket package for a quadEM driver for the FX4 electrometer, produced by Pyramid Tech and also sold by XDSOxford:

https://pyramid.tech/products/fx4?srsltid=AfmBOorDnrjB9if5PRTZfF79J5GHg_Us9DnrnZjbsecJmfi0fVtSHshe
https://xds-oxford.com/products/detectors-diagnostics/control-modules/fx4-4-channel-precision-electrometer/

IXWebSocket is a very nice package that builds without warnings on Linux and Windows.  However, they don't use macros to decorate the class names, so it would require editing their source to allow the optional __declspec(dllexport).


In this case it was cleaner to not build IXWebsocket as a separate library, but rather directly into the FX4 driver library.  That way none of the IXWebSocket functions need to be exported.  It is working on both windows-x64 and windows-x64-static now.

Thanks,
Mark



From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Freddie Akeroyd - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, June 9, 2026 7:31 PM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: RE: Strange problem linking a library on windows-x64

Hi Mark,

 

In a dynamic build ixwebsocket.lib is the import library containing the exported symbol references from the DLL, if the DLL has no symbols exported then I believe link will not create an import library. You can confirm whether the DLL exports any symbols by running

 

    dumpbin  /exports ixwebsocket.dll

 

To resolve this check the header files for the library, there may be some additional preprocessor symbol that needs defining during an EPICS dynamic build so that the library source adds     __declspec(dllexport)   to relevant functions to  create an import library.     

 

Regards,

 

Freddie

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: 09 June 2026 22:47
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Strange problem linking a library on windows-x64

 

Folks,

 

I am having a strange problem linking a library on windows-x64 (dynamic build).  The library compiles and links fine on windows-x64-static (static build).

 

On windows-x64 the library compiles fine, but generates this error when linking:

 

link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:ixwebsocket.dll -implib:ixwebsocket.lib     IXBench.obj IXCancellationRequest.obj IXConnectionState.obj IXDNSLookup.obj IXExponentialBackoff.obj IXGzipCodec.obj IXHttpClient.obj IXHttp.obj IXHttpServer.obj IXNetSystem.obj IXSelectInterrupt.obj IXSelectInterruptEvent.obj IXSelectInterruptFactory.obj IXSelectInterruptPipe.obj IXSetThreadName.obj IXSocketAppleSSL.obj IXSocketConnect.obj IXSocket.obj IXSocketFactory.obj IXSocketMbedTLS.obj IXSocketOpenSSL.obj IXSocketServer.obj IXSocketTLSOptions.obj IXStrCaseCompare.obj IXUdpSocket.obj IXUrlParser.obj IXUserAgent.obj IXUuid.obj IXWebSocketCloseConstants.obj IXWebSocket.obj IXWebSocketHandshake.obj IXWebSocketHttpHeaders.obj IXWebSocketPerMessageDeflateCodec.obj IXWebSocketPerMessageDeflate.obj IXWebSocketPerMessageDeflateOptions.obj IXWebSocketProxyServer.obj IXWebSocketServer.obj IXWebSocketTransport.obj        ws2_32.lib crypt32.lib bcrypt.lib

Generating code

Finished generating code

"Installing shared library ../../../../bin/windows-x64/ixwebsocket.dll"

"Installing library ../../../../lib/windows-x64/ixwebsocket.lib"

installEpics.pl: No such file 'ixwebsocket.lib' at H:/epics-devel/base-7.0.10/bin/windows-x64/installEpics.pl line 54.

make[3]: *** [H:/epics-devel/base-7.0.10/configure/RULES_BUILD:489: ../../../../lib/windows-x64/ixwebsocket.lib] Error 2

make[3]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/FX4Src/ixwebsocket/O.windows-x64'

make[2]: *** [H:/epics-devel/base-7.0.10/configure/RULES_ARCHS:58: install.windows-x64] Error 2

make[2]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/FX4Src/ixwebsocket'

make[1]: *** [H:/epics-devel/base-7.0.10/configure/RULES_DIRS:85: FX4Src/ixwebsocket.install] Error 2

make[1]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp'

make: *** [H:/epics-devel/base-7.0.10/configure/RULES_DIRS:85: quadEMApp.install] Error 2

 

Note that the link command did not generate an error.  However, there is an error when it tries to install the ixwebsocket.lib.  The problem is that the library file is not being created.

 

If I cd to the O.windows-x64 directory and manually type the "link" command it completes with no errors:

 

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:ixwebsocket.dll -implib:ixwebsocket.lib     IXBench.obj IXCancellationRequest.obj IXConnectionState.obj IXDNSLookup.obj IXExponentialBackoff.obj IXGzipCodec.obj IXHttpClient.obj IXHttp.obj IXHttpServer.obj IXNetSystem.obj IXSelectInterrupt.obj IXSelectInterruptEvent.obj IXSelectInterruptFactory.obj IXSelectInterruptPipe.obj IXSetThreadName.obj IXSocketAppleSSL.obj IXSocketConnect.obj IXSocket.obj IXSocketFactory.obj IXSocketMbedTLS.obj IXSocketOpenSSL.obj IXSocketServer.obj IXSocketTLSOptions.obj IXStrCaseCompare.obj IXUdpSocket.obj IXUrlParser.obj IXUserAgent.obj IXUuid.obj IXWebSocketCloseConstants.obj IXWebSocket.obj IXWebSocketHandshake.obj IXWebSocketHttpHeaders.obj IXWebSocketPerMessageDeflateCodec.obj IXWebSocketPerMessageDeflate.obj IXWebSocketPerMessageDeflateOptions.obj IXWebSocketProxyServer.obj IXWebSocketServer.obj IXWebSocketTransport.obj        ws2_32.lib crypt32.lib bcrypt.lib

Generating code

Finished generating code

 

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>

 

It should have created ixwebsocket.dll and ixwebsocket.lib.  However, when I look for those files in the O.windows-x64 directory only the .dll file exists, not the .lib file:

 

J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64>dir *.lib *.dll

 Volume in drive J is people_rw

 Volume Serial Number is 5005-CD09

 

 Directory of J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64

 

 

 Directory of J:\epics\devel\quadEM\quadEMApp\FX4Src\ixwebsocket\O.windows-x64

 

06/09/2026  04:37 PM           284,672 ixwebsocket.dll

               1 File(s)        284,672 bytes

               0 Dir(s)  9,569,302,556,672 bytes free

 

 

I have never seen this problem before.  Any idea what could cause it?

 

Thanks,

Mark

 

 

 

]]> https://epics.anl.gov/tech-talk/2026/msg00679.php Mark Rivers via Tech-talk Wed, 10 Jun 2026 14:37:51 GMT DM3PPF1CEB6B7EF0136CFE4071F44895B73991A2@DM3PPF1CEB6B7EF.namprd11.prod.outlook.com Problem building on windows-x64
Subject: Problem building on windows-x64
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 14:37:51 +0000
Folks,

I am having intermittent problems building on windows-x64.  I get errors like this:

link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release  -MACHINE:X64           -out:quadEM.dll -implib:quadEM.lib     drvQuadEM.obj drvSoftQuadEM.obj        J:/epics/devel/areaDetector-3-14/ADCore/lib/windows-x64/ADBase.lib  J:/epics/devel/asyn-4-46/lib/windows-x64/asyn.lib  J:/epics/devel/areaDetector-3-14/ADCore/lib/windows-x64/ntndArrayConverter.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/nt.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/pvDatabase.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/pvAccess.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/pvData.lib  J:/epics/devel/pvxs/lib/windows-x64/pvxsIoc.lib  J:/epics/devel/pvxs/lib/windows-x64/pvxs.lib  J:/epics/devel/areaDetector-3-14/ADCore/lib/windows-x64/ntndArrayConverterPvxs.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/netCDF.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/nanohttp_stream.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/Magick++.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/coders.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/Magick.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/jbig.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/jp2.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/bzlib.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/png.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/webp.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/lcms.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/ttf.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/wmf.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/filters.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/tiff.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/xml2.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/NeXus.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/hdf5_hl.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/hdf5.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/bitshuffle.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/lz4hdf5.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/blosc.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/szip.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/zlib.lib  J:/epics/devel/areaDetector-3-14/ADSupport/lib/windows-x64/jpeg.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/dbRecStd.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/dbCore.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/ca.lib  H:/epics-devel/base-7.0.10/lib/windows-x64/Com.lib  J:/epics/devel/pvxs/bundle/usr/windows-x64/lib/event_core.lib gdi32.lib oleaut32.lib bcrypt.lib iphlpapi.lib netapi32.lib ws2_32.lib
   Creating library quadEM.lib and object quadEM.exp
LINK : fatal error LNK1104: cannot open file 'quadEM.exp'
make[1]: *** [H:/epics-devel/base-7.0.10/configure/RULES_BUILD:317: quadEM.dll] Error 1104
make[1]: Leaving directory 'J:/epics/devel/quadEM/quadEMApp/quadEMSrc/O.windows-x64'
make: *** [H:/epics-devel/base-7.0.10/configure/RULES_ARCHS:58: install.windows-x64] Error 2

Note that is says it could not open quadEM.exp.  However, it actually did create that file as seen here:

J:\epics\devel\quadEM\quadEMApp\quadEMSrc>dir O.windows-x64
 Volume in drive J is people_rw
 Volume Serial Number is 5005-CD09

 Directory of J:\epics\devel\quadEM\quadEMApp\quadEMSrc\O.windows-x64

06/10/2026  09:30 AM    <DIR>          .
06/10/2026  09:29 AM    <DIR>          ..
06/10/2026  09:29 AM               202 Makefile
06/10/2026  09:29 AM             4,135 drvSoftQuadEM.d
06/10/2026  09:29 AM             3,852 drvQuadEM.d
06/10/2026  09:29 AM         1,705,689 drvQuadEM.obj
06/10/2026  09:29 AM         1,623,888 drvSoftQuadEM.obj
06/10/2026  09:30 AM             7,059 quadEM.exp
06/10/2026  09:30 AM            12,070 quadEM.lib
               7 File(s)      3,356,895 bytes
               2 Dir(s)  9,567,843,336,192 bytes free

The problem is intermittent, if I try to build several times eventually it usually works.

My EPICS files reside on a Linux file server which is mounted with SMB from the Windows workstation.  This has worked fine for 20+ years.  But recently I started having these problems.  I have not changed the Visual Studio environment recently, and it was previously working.  The Linux OS (RHEL 9.7) and the Windows 11 OS are relatively new.  I am suspecting a problem with file locking or file caching on the SMB files.  Has anyone else run into this problem?

Thanks,
Mark

]]> https://epics.anl.gov/tech-talk/2026/msg00680.php Érico Nogueira Rolim via Tech-talk Wed, 10 Jun 2026 20:15:56 GMT aec321d4-03a0-4e3b-9fe5-03b5059c3a23@lnls.br Re: AreaDetector Collaboration Meeting - June 11th
Subject: Re: AreaDetector Collaboration Meeting - June 11th
From: Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 10 Jun 2026 20:15:56 +0000 
Hi folks!

This month's meeting will be on June 11th 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: ADAndor, ADCSimDetector,
ADCompVision, ADCore, ADDexela, ADEiger, ADLambda, ADLightField,
ADMythen, ADPICam, ADPerkinElmer, ADSBIG, ADSupport, ADTimePix3,
ADViewers, NDDriverStdArrays, areaDetector.

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!cP2u1cy5FvqGta458aPvqSxL932uYs9Mvm-hwTY1BJ3HwpE_zdc6nr_rNqkEUzzz5KzWMyFciVMpj-I3sURyITxrYng$ 


EPICS Chat Server: https://urldefense.us/v3/__https://epics-controls.org/epics-chat/__;!!G_uCfscf7eWS!cP2u1cy5FvqGta458aPvqSxL932uYs9Mvm-hwTY1BJ3HwpE_zdc6nr_rNqkEUzzz5KzWMyFciVMpj-I3sURyrFOr4x8$ 

Meeting agenda:
https://urldefense.us/v3/__https://github.com/areaDetector/collaboration/blob/master/2026-06-11.md__;!!G_uCfscf7eWS!cP2u1cy5FvqGta458aPvqSxL932uYs9Mvm-hwTY1BJ3HwpE_zdc6nr_rNqkEUzzz5KzWMyFciVMpj-I3sURyxdWpkOg$ 

Cheers,
Érico

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.
]]>