Hobbyist Toolkit
Run Python Nodes on rPI 4
Solved!
Hi,
I'd like to make use of the Python nodes on a code running on a rPI 4 (LINX installed).
It seems that I'm not really successfull to do so.
Does anyone have the magical recipe from Python installation to running the Python nodes on rPi ?
As soon as I run the code below (Python installed or not...) it just crashes the rPi.
Any idea ?
My guess is that you installed Python on the Raspian host OS from the standard Raspberry Pi software updater. But your LabVIEW executable runs in its own chroot VM with its own Linux OS.
Or did you go into the chroot environment itself through an SSH prompt and install Python through an opkg command on the command line?
Hi Rolfk,
Indeed I installed it on the Raspbian side.
So I need to install it into the chroot jail.
Any idea on how I can do so?
I'm used to use Putty on a cRIO, but I don't know how to enter the LinuxRT OS itself.
If you are familiar with use of putty, you are almost there.
Once inside the Rasperry Pi you enter:
sudo schroot -r -c lv
opkg update
opkg install python3
The last command is just an assumption, I didn't try it. I'm quite sure NI placed some python build packages on their servers. If it isn't there you might instead have to recompile python from sources. For that you would have to install at least the
opkg install packagegroup-core-buildessential
maybe git too depending how you want to download the python sources.
Thanks !
I'll give it a try (vacations homework 🙂)
No problem compiling it from source, that's what I did on Raspbian already.
I'll validate the answer and/or post corrections here.
Update opkg shows that the feed are targetting a labviewmakerhub feed.
And this one seems less furnished than the usual NI feed (just a feeling here, might get wrong).
opkg install python3 doesn't work.
When doing an opkg list we can see that there is a python package available but in version 2.7.9...
Rather old.
So I went to the path of getting the Python 3 source.
I installed core-buildessential and git client (even if not needed actually).
And downloaded the 3.9.9 version of Python using wget https://www.python.org/ftp/python/3.9.9/Python-3.9.9.tgz
After unpacking the tar, I ran the ./configure script.
But it ends up like this :
./configure --prefix=/usr/local/python3.9 --enable-optimizations --enable-shared
checking build system type... armv7l-unknown-linux-gnueabi
checking host system type... armv7l-unknown-linux-gnueabi
checking for python3.9... no
checking for python3... no
checking for python... no
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "linux"
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/usr/src/Python-3.9.9':
configure: error: C compiler cannot create executables
See `config.log' for more details
config.log didn't help much.
I discovered that gcc version is 4.9 (kind of old) and the configure script has special branching for gcc version below 5 ...
I tried upgrading gcc but without success from opkg...
😞
Anyhting you would recommend ?
Welcome to Linux version hell :-). Where changing one little dependency forces you to hunt down a whole slide of other dependencies and eventually end up in the abyss of incompatible versions and dragons. Your Python 3.9.9 make scripts can't be bothered to work with a somewhat older gcc installation it would seem. Upgrading gcc however is the superlative of version hell, so that is generally the absolute last thing you should try on any specific system (unless it is fully supported by the actual package installer tools). Going back to an earlier version of Python is most likely the path of least resistance.
I tried getting gcc sources to compile it.
It seems that current release is 12.0.
And the one shipped with NI feeds is v4...
Such a pitty that it is far behind current releases.
Same thing on the cRIOs, it begins to be problematic.
My understanding of the script shows that any python 3+ needs gcc v5+.
Si that would mean I need to feel back to Python 2.7 (which is included on the Linx image / opkg feeds). 🙄😑🥴😒
From what I understand, I would have the same problems on the cRIO.
That is very disappointing. No should do something to be more up to date on their Linux packages.
It will become problematic if some hacker try to exploit CVE known issues on such devices...
At the end it doesn't help me much with my problem.
Do you know if it enters into NI support perimeter ?
Actually, from viewing this, cRIOs would certainly seem to have a somewhat/significantly different experience.
GCC 4.9 (and kernel 4.1) were used to build nilrt 4.0 (which corresponds to NI Linux for LabVIEW 2016. Seems the Raspberry and Beaglebone Black images you use are based on this.
Current nilrt 9.0 (NI Realtime 2022.5) uses gcc 10.2 and Linux kernel 5.10. And Python2 support was completely removed and Python3 support is standard since a few versions. So unless you work with a rather old NI Realtime version, cRIOs certainly would have a rather different experience. But of course they do cost a little more than a Raspberry Pi.
Indeed!
Having a nilrt 5.0 or even better 7.0 (Python 3 by default) would be the best on a rPi.
Do you know if there is a plan for NI to update the LINX toolkit to target an updated version?
It would be nice to have something a bit more up to date...
LINX looks like abandoned to me (few caveats installing it on rPi4, not a good integration with LV pro,...).
For the moment I'd consider having the Python nodes running on rPi not possible since we must target Python 3.6 to 3.9 with these nodes.
