Migrating OPC UA Client Custom Device to VeriStand 2025 Q3 - Deployment fails with "The VI is not executable"

[TintinC]

Hi everyone,

I am currently migrating the OPC UA Client Custom Device available on GitHub to LabVIEW 2025 and NI VeriStand 2025 Q3.

Repository: https://github.com/NIVeriStandAdd-Ons/OPC-UA-Client-Custom-Device

Software environment

• LabVIEW 2025 (64-bit)
• NI VeriStand 2025 Q3
• NI Linux RT 2025 Q3
• NI OPC UA Toolkit 2025
• Application Modeling Components (AMC) 2025
• Target: NI sbRIO-9603 (Linux ARM)

Migration work already completed

I migrated the original LabVIEW 2019 source to LabVIEW 2025 by performing the following steps:

• Opened and saved the project in LabVIEW 2025
• Installed all required dependencies:
  • NI OPC UA Toolkit 2025
  • Application Modeling Components (AMC)
• Updated the .lvproj.config assembly binding redirects (VeriStand assemblies)
• Fixed all broken .NET references
• Fixed all broken VIs caused by missing dependencies
• Performed a full Mass Compile of the source tree
• Corrected Build Specification issues (Source File Settings → Use Default Save Settings)

All Engine Release builds now compile successfully:

• Windows
• Linux x64
• Linux ARM

Verification performed

I verified the following:

• No broken VIs remain in the project.
• No broken VIs remain inside the generated LLBs.
• RT Driver.vi is present inside every generated LLB.
• The complete RT Driver VI hierarchy is valid.
• RT Driver.vi can be opened directly from the generated LLB.
• RT Driver.vi can be executed directly on the sbRIO.
• The Custom Device XML correctly references the generated LLBs and RT Driver.vi.
• The OPC UA Toolkit works correctly on the target (NI examples deploy successfully).

Current behavior

Inside VeriStand:

• The Custom Device loads correctly.
• The configuration pages work.
• OPC UA server discovery works.
• Browsing the OPC UA address space works.
• Variables can be imported into the System Definition.

The problem only occurs during deployment.

Deployment error

During deployment VeriStand reports:

LabVIEW:
The VI is not executable.
This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate.

NI VeriStand Engine
→ Initialize Inline Custom Devices.vi
→ Custom Devices Storage.lvlib
→ Initialize Device (HW Interface).vi

Error 1003

Interestingly, the error no longer explicitly mentions RT Driver.vi.

Question

Has anyone successfully migrated this Custom Device (or any Inline Async Custom Device) to VeriStand 2025 ?

Are there any known framework changes between VeriStand 2024 and 2025 that could explain this deployment failure despite a successful build and no broken VIs?

Finally, would you recommend:

1. continuing to debug and migrate the existing project, or
2. migrating the OPC UA implementation into a new Custom Device generated by the VeriStand 2025 Custom Device Wizard?

The second option seems possible but would require a much larger migration effort, so I'd like to know whether anyone believes it is actually necessary or if there is a simpler solution.

Any advice or feedback would be greatly appreciated.

Thank you!

[Jacobson]

Are the OPC UA examples using the same API calls that the CD is? I remember the API being updated at some point so maybe the CD is using some deprecated VIs that aren't deploying.

[TintinC]

Thanks Jacobson for your suggestion.

I checked the OPC UA Toolkit API in detail and, as far as I can tell, the custom device is not using deprecated OPC UA VIs. After upgrading the project to LabVIEW 2025 / VeriStand 2025 Q3, all OPC UA Toolkit VIs are resolved correctly and there are no broken OPC UA VIs anymore.

I also verified that the standard NI OPC UA examples deploy and run correctly on the same sbRIO, so the OPC UA Toolkit itself appears to be working properly on the target.

After looking at the RT logs, I noticed the following error:

OPC UA Client (v1.0.2): Started...
******************************
OPC UA Client error encountered.
Error code: -2206
LabVIEW: (Hex 0xFFFFF762) RT FIFO does not exist.
******************************
OPC UA Client (v1.0.2): Stopped...

I then traced where this log message is generated.

By following the callers step by step, I ended up in:

vi.lib\NI\NIVS Inline Async API\_VS Inline Async API\
VS Inline Async API\SubVIs\Connect to Error Handles.vi

This VI does not generate the error itself. It only catches the RT FIFO error and converts it into error -2206 ("RT FIFO does not exist") before logging it.

From there, I continued tracing the call hierarchy backwards until reaching the initialization sequence of the custom device:

RT Driver.vi
    ↓
RTMain.Initialize.vi
    ↓
Async.Engine.Initialize.vi
    ↓
Connect to Error Handles.vi

So, at the moment, it looks like the failure actually occurs before Connect to Error Handles.vi. This VI is only reporting an error that has already occurred earlier during the initialization of the RT engine.

My current hypothesis is that one of the initialization VIs fails before the asynchronous processes (or their RT FIFOs) are successfully created, which then causes Connect to Error Handles.vi to fail when it tries to connect to them.

At this point, I don't have evidence that the OPC UA API itself is the problem. The OPC UA VIs compile correctly and the standard NI examples work on the target.

My question is therefore: Has anyone seen changes in the VS Inline Async API or the Custom Device framework between older VeriStand versions and VeriStand 2025 that could cause this type of initialization failure?

Even if the VIs are not broken after recompilation, could there be API or framework changes that require modifications to the initialization code of an older custom device?

[TintinC]

Small update after a lot more debugging.

At this point, I no longer believe the issue is in the VeriStand Inline Async API or the Custom Device framework itself.

Here is what I found:

• Run Process.vi successfully opens Poll.Main.vi (Open VI Reference OK).
• Poll.Main.vi is actually started correctly.
• The -2206 (RT FIFO does not exist) error is only a consequence: the FIFO is never created because the asynchronous process terminates before reaching the FIFO initialization.

To isolate the problem, I progressively removed code from Poll.Main.vi.

• If I remove all OPC UA Toolkit dependencies, Poll.Main.vi starts normally and my debug message (Async Started) appears in the RT log.
• As soon as I add back the first OPC UA-related code (or even some OPC UA Toolkit typedefs/controls used by Poll.Initialize.vi), the process no longer starts and Async Started never appears.

This strongly suggests that the failure occurs while loading or initializing the OPC UA Toolkit dependencies, before the code can actually execute.

I also verified the following:

• The OPC UA runtime package (ni-opc-ua) is installed on the sbRIO.
• libni_opcua.so is present on the target (/usr/local/lib/libni_opcua.so).
• The Custom Device is correctly deployed on the target.
• Open VI Reference succeeds for Poll.Main.vi.

So at this point, the problem no longer looks related to the Async API, FIFO management, or deployment.

The current evidence points to something related to the OPC UA Toolkit itself (or its interaction with VeriStand 2025 Q3/Linux RT), because the mere presence of OPC UA Toolkit VIs or typedefs inside Poll.Initialize.vi is enough to prevent the asynchronous process from starting.

Has anyone seen this kind of behavior before, or have any ideas on what I should investigate next?

At this point, I feel like I've checked everything I can think of:

• the deployment,
• the Inline Async API,
• the Custom Device itself,
• the OPC UA runtime installation on the target,
• and the loading of the asynchronous process.

I'm running out of ideas, so any suggestion would be greatly appreciated.

Thanks in advance!

[ZYOng]

VeriStand 2021 or later does not support 32-bit ARM Linux RT.

Reference: Cannot Add NI Veristand Engine on cRIO-9068

[TintinC]

Hello ZYOng,

I don't quite understand the point of this comment.

The sbRIO I'm using as a target is indeed running Linux x64. (sbRIO-9603 Specifications - NI)
And I'm compiling the x64 version of the OPC UA add-on custom device project.

Have I forgotten something? ...

Thanks in advance,

[TintinC]

Edit: I just noticed that I wrote “ARM” in my first post...

So that was a mistake: my apologies.

Thanks for your message,

[ZYOng]

I would recommend debugging the RT Driver deployment first on Windows.

It is much easier to isolate the dependencies issue on Windows and also troubleshooting bug as you can configure subVI to open the front panel for debugging when called.

[TintinC]

Hello ZYOng,

But that's exactly what I did:
- Deployed the RT Driver VI.vi directly to the target from the lvproj.

--> No problems, no broken wires, no errors related to the OPC UA API... The deployment goes smoothly.

But when I build and deploy in Veristand, as soon as the OPC UA API is called, it causes the Poll.Main.vi to crash immediately.It happens immediately—because if I disable everything related to OPC UA in Poll.Main.vi, it works.

So I don’t know what to debug after all...

Thanks

[TintinC]

Hello,

Any other ideas?

I’ve run quite a few tests, and ultimately, simply adding a Call Library Function Node that points to the .dll (or the .so on the cRIO) causes any VI to crash when it’s called by the Veristand Async API.

For now, I’ve concluded that this is the only cause of the crash.

I also tried again with a cRIO 9045 formatted with only the necessary software, and the same thing happened—it crashes when calling the .dll (or the .so, again...).

Thanks in advance,