LabVIEW 2022 Q3: "The Python session refnum input is not valid" after Create SubVI

[Nika26]

Hello,

I developed and tested my application in LabVIEW 2026, where everything worked without any issues.

Afterwards, I saved the project back to LabVIEW 2022 Q3 because I needed to support an older LabVIEW version. From that point on, I always got the following error:

Error 1666

LabVIEW: (Hex 0x682) The Python session refnum input is not valid.

At first, I thought the problem was caused by saving the project back to LabVIEW 2022. Therefore, I created a completely new project in LabVIEW 2022 Q3 and rebuilt everything from scratch. Surprisingly, everything worked.

After that, I started refactoring the code by splitting it into SubVIs, just like in my original project. As soon as I did that, the exact same error appeared again.

I spent quite some time debugging this. I verified with probes that the Python Session Refnum is wired correctly, the connector panes are correct, and no inputs or outputs are mixed up.

After a lot of testing, I found a reproducible behavior:

- Open Python Session in one SubVI and the Python Node in another SubVI -> Works
- Open Python Session in the main VI and the Python Node in a SubVI -> Works
- Open Python Session and the Python Node inside the same SubVI -> Error 1666
- If I simply select both nodes and use "Create SubVI", without changing anything else, the generated SubVI immediately fails with Error 1666.

I have attached three screenshots:
- Works1: Open Python Session in the main VI, Python Nodes in SubVIs.
- Works2: Open Python Session in its own SubVI, Python Nodes in separate SubVIs.
- Fails1: The Open Python Session SubVI and the first Python Node SubVI were merged into a single SubVI. This immediately results in Error 1666.

Has anyone experienced this before? Is this a known limitation or a bug in LabVIEW 2022 Q3? Any ideas or suggestions would be greatly appreciated.

Thank you!

[Yamaeda]

In the last one you never open a Python reference, you send an empty object ref as input.

If you post your VI's it's easier to check ...

[Nika26]

The Python session is actually opened inside the first VI. The first VI contains both Open Python Session and the first Python Node. The Python Session Refnum and the Python Object Refnum are both passed through the connector pane to the next VI. The only difference is that when Open Python Session and the first Python Node are placed together inside the same VI, I get Error 1666. If I separate them into two VIs, everything works.

I have already verified that this is not caused by incorrect wiring, swapped inputs/outputs, or a wrong connector pane. I checked everything carefully with probes and by rebuilding the VIs from scratch.

Also, unfortunately sending the VIs would probably not help. The Python session is used to control custom hardware, so the project can only be executed in this specific environment.

[Nika26]

I was able to reproduce the issue with a much simpler project, which I have attached.

The same error still occurs, and the behavior is identical to my original project.

I can also confirm that this issue only occurs in **LabVIEW 2022 Q3**. The exact same project works correctly in **LabVIEW 2026**.

[rolfk]

Python Object references were a new feature in LabVIEW 2022 Q3 and yes there were some problems with them in that version. So you will likely have to use a newer LabVIEW version if you need this to work.

And yes the name is a little misleading since these are unlike other LabVIEW refnums not exactly references. They behave more like by value objects which is the reason that you have to wire them through the node and can't just branch them off if the node modifies the object in any way. Never tried to put nodes using them into subVIs but that seems a different although possibly related issue.

NI is usually not updating previous versions before the current one for anything but security fixes and even that only for the 3 years prior to the current version.

[Nika26]

I tested it with LabVIEW 2023 Q3 and encountered the same error. LabVIEW 2023 Q3 is still supported, so the issue is not limited to LabVIEW 2022 Q3.

​Software Product Lifecycle Policies​ - NI

[rolfk]

---

@Nika26 wrote:

I tested it with LabVIEW 2023 Q3 and encountered the same error. LabVIEW 2023 Q3 is still supported, so the issue is not limited to LabVIEW 2022 Q3.

​Software Product Lifecycle Policies​ - NI

---

That may as well be but that lifecycle support basically means something else than what you would like.

Starting this year a software producer needs to update active software with security fixes for (generally) 5 years, NI did do 4 years until now but will increase that to 5 years starting from this point on. And no that will not make your 2022Q3 suddenly active, it only means they won't make 2023Q3 unsupported with the next release of LabVIEW. Active software in this sense means still officially distributed, so there is actually a good chance that older downloads than that are simply removed from now on, so it may be a good idea to download such installers now and archive them somewhere if you expect to need them in the future.

However, supported basically means, aside from that technical support will try to give support for problems reported by users, that they will fix accepted security vulnerabilities; that means software bugs with an official CVE assignment that have a potentially significant influence on the security of the system. It does not mean that they will do bug fixes on such old versions that have not a CVE assignment. And you will be hard pressured to get the relevant instances recognize this bug as a CVE worthy issue.

Bug fix releases are generally only done for the latest version and in the case when that is an intermediate version such as what the Q1 versions usually are, also for the previous stable version which is usually Q3. Even security updates are only done to the stable (Q3) versions and usually not to the intermediate versions at all.

Your issue is gone in the latest 2026 Q3 version, and was already fixed in 2025 Q3 (the oldest I have installed on this machine) but possibly earlier so as far as NI is concerned this issue is fixed,