Setup:
- LabVIEW 2021 SP1, 32-bit
- TestStand 2020, 32-bit
- Test module built as a DQMH module, compiled into a Packed Project Library (.lvlibp)
- Pickering PXI switching card (40-140-221), driver package PIPX40 / Pilpxi installed via official Pickering PXI Driver Package (dated 2024-10-02)
- Module invoked from TestStand via LabVIEW Adapter, Run-Time Engine 2021 SP1 (same version as development)
Problem:
Our DQMH module opens a PIPX40 session, sets a relay channel (Set Channel = True), waits, then reads it back (Get Channel). Symptoms:
Get Channel consistently returns False even right after setting True.
A subsequent Reset call on the same session consistently fails with the error "not a valid pipx40 session handle", even though the Call ID / session handle probed at that point looks numerically valid.
Running the exact same module logic manually from the LabVIEW IDE (via our DQMH tester) always works correctly.
Running it from TestStand (via LVRT) fails consistently.
As a workaround, if we open TestStand's Configure > Search Directories dialog (without making any change) and close it, the problem temporarily disappears for subsequent runs.
Investigation so far:
- Confirmed via a minimal standalone VI (Open → Set → wait → Get → Close, no DQMH, no TestStand) that the driver/hardware itself behaves correctly when run in the LabVIEW IDE.
- The CLFN "Library name or path" field in our PIL wrapper VIs is configured as pipx40_32.* (no explicit path — presumably inherited default from Pickering's example VIs), relying on Windows' standard DLL search order.
- Our .lvlibp/VI hierarchy physically resides under a project folder structure that itself contains several old orphaned copies of pipx40_32.dll (284,160 bytes, dated 2017–2023) left over from unrelated older projects, alongside the official current DLL at C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin\pipx40_32.dll (722,432 bytes, current driver version).
- Our working theory: because the CLFN uses only the DLL name (no path), and Windows' DLL search order gives priority to the calling executable's directory, the LVRT process (spawned by TestStand) may be resolving pipx40_32.dll from one of the old local copies instead of the official one — while the LabVIEW IDE tester resolves it correctly. This would explain both the "always false on Get" (old DLL, different/incompatible internal session table) and "invalid session" on Reset.
We have not yet been able to confirm this via Process Explorer (DLL load path per process was inconclusive in our attempt).
We cannot remove the old orphaned DLL copies from part of that folder tree (shared/read-only project area).
Questions:
- Is there a recommended, supported way to force a Call Library Function Node to resolve a Pickering driver DLL from an explicit, guaranteed path when the VI hierarchy itself resides in a folder tree containing other (older) copies of the same-named DLL? Is hardcoding the absolute path in the CLFN the correct approach, or is there a better-supported mechanism?
- Does Pickering's PIPX40 driver maintain any internal state (session table, handles) that is scoped per loaded DLL instance rather than purely per Call ID? We are trying to understand whether having two different physical copies of pipx40_32.dll loaded in two different processes (LabVIEW.exe vs lvrt.exe) could produce exactly this kind of session mismatch.
- Why would opening/closing TestStand's Search Directories dialog (no changes made) apparently force a full reload of the LabVIEW Adapter's cached VI/DLL references? Is there a supported, scriptable equivalent we could call automatically (e.g., in our sequence's Cleanup or Setup) to guarantee this reload happens on every run?
Thanks
