Error 1672 occurs in the "Open Python Session" function

[yamama]

Hello,

I would like to use Python in LabVIEW, but Error 1672 occurs when I run the "Open Python Session" function. The error message doesn't provide any details other than the source.

The VI is very simple:

The LabVIEW version I am using is 2023Q1, and the result of python -V is Python 3.8.10. The Python executable path in Windows 11 is correctly set in the system PATH.

Initially, I installed Python 3.10, followed by 3.9, and then 3.8. When the error occurred, I uninstalled all Python versions and reinstalled only Python 3.8. No additional packages were installed except for pip and setuptools. However, the error persisted.

To troubleshoot, I installed Python 3.8 on another PC, and it worked without any issues. On that PC, the pip list result shows the following installed packages:

Package Version
--------------- -----------
cycler 0.12.1
kiwisolver 1.4.7
matplotlib 3.3.3
numpy 1.22.4
pandas 2.0.3
pillow 10.4.0
pip 21.1.1
pyparsing 3.1.4
python-dateutil 2.9.0.post0
pytz 2024.2
scipy 1.6.3
setuptools 56.0.0
six 1.17.0
tzdata 2024.2

Given that it works fine on the other PC, it seems clear that the issue is specific to my PC. Could you please help identify what I might have overlooked?

[Andrey_Dmitriev]

If your Python is properly installed and reachable through PATH Variable, then you don't need to specify path, just version, this is sufficient.

Also check bitness of the installed Python in LabVIEW, both must be the same (both 32 or both 64 bit)..

Refer to Integrating Python Code in LabVIEW.

[yamama]

Thank you for your quick reply.

I forgot to include some important information. Both LabVIEW and Python are 32-bit versions. My PC is 64-bit, but only the 32-bit version of LabVIEW is distributed in my lab.

The error still occurs even without the PATH variable.

[rolfk]

In your image the path looks borked. That Yen character instead of the backslash would indicate that you work on a non English locales system, maybe Japanese?, but something is not setup right. LabVIEW should NOT represent paths with that characters seperator unless something is borked with the language setup. That might trip up several things further down the code chain.

[Andrey_Dmitriev]

---

@rolfk wrote:

In your image the path looks borked. That Yen character instead of the backslash would indicate that you work on a non English locales system, maybe Japanese?, but something is not setup right. LabVIEW should NOT represent paths with that characters seperator unless something is borked with the language setup. That might trip up several things further down the code chain.

---

But he wrote "The error still occurs even without the PATH variable."

Technically when Python Open Session called without path, then it take a look for ExecutablePath Key in the registry

HKLM\SOFTWARE\Python\PythonCore\3.8\InstallPath

My be the Yen character is also entered into the registry, then this could explain this fact. The Error code 1672 is also interesting — I can easily provocate 1671, but not 1672.

[rolfk]

---

@Andrey_Dmitriev wrote:

---

@rolfk wrote:

In your image the path looks borked. That Yen character instead of the backslash would indicate that you work on a non English locales system, maybe Japanese?, but something is not setup right. LabVIEW should NOT represent paths with that characters seperator unless something is borked with the language setup. That might trip up several things further down the code chain.

---

But he wrote "The error still occurs even without the PATH variable."

Technically when Python Open Session called without path, then it take a look for ExecutablePath Key in the registry

HKLM\SOFTWARE\Python\PythonCore\3.8\InstallPath

My be the Yen character is also entered into the registry, then this could explain this fact. The Error code 1672 is also interesting — I can easily provocate 1671, but not 1672.

---

Yes I did not say that that path in itself was the problem, but the fact that it is displayed like that in LabVIEW would hint at some weird system setup and that might influence how LabVIEW reads the registry to determine the path where Python is installed. I don't think the path is like that in the registry, the registry is storing everything as Unicode for a long time already, but LabVIEW is still a 8 bit MBCS application and when reading from the registry will ultimately have to convert the data into the locale MBCS string and if something is setup badly here, the path operations will sooner or later get into a fit.

[yamama]

Thank you for your discussion.
I believe the Yen character, instead of the backslash, does not cause any issues because it is commonly used as a path separator in Japan. I usually use it in LabVIEW, and as I mentioned, the VI works on another PC.