From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Labview for raspberry pi 3
@Hooovahh wrote:
wiebe@CARYA wrote:
There are SSE compiler property nodes (both Application and VI). Scripting of course and private of course. Ned (, the friendly configuration manager,) allows setting some options as well. Not sure how much of this is in the open...
If it is on the VI level, then does that mean it needs to be run on all VIs? I really thought this might just be an INI setting in the lvproj that was hidden. But it is possible that NI really just wanted to cut off having to support legacy processors, and removed the functionality all together.
The description of the VI property says that it disables SSE optimization on the VI. So that would mean it needs to be set to false for all VIs (and then back again).
The Application options might globally overwrite this.
But I really don't know.
Can't test it right now, but if I understand correctly, there is now a W10 image available. This was the showstopper for me. The MS Insiders program just didn't work for me (still saying I'm in the program, until I need to use it).
@Hooovahh wrote:Yes re-imaging the Pis drive back to the start takes about a minute. Still when testing what needs to be installed to make things happy, it is easier to use a fresh version of Windows in a VM that supports snapshots.
Ah, so sort of a simulation of the Pi on a normal Windows 10 version, to test LabVIEW RTE installation? We had to do that at some point for a boxed app. But this simulation doesn't fail when SSE is on, right? Or can you actually run the Pi image in a VM? I did that in the passed (using QEMU), but I only succeeded because the right bootloader and images where online.
Thinks where easier in LV5... Well, those things.
Search LabVIEW like a graph! 
Sorry if I wasn't clear. I have two environments to test things with. The real Pi4, with a real SSD. Plugging this SSD into my desktop I can put an image on it that is a blank Windows 10. Imaging this drive takes about a minute, then I can move it back to the real Pi, boot it up and play around. Figuring out what installers are needed, and how to run them silently is a pain in this environment since you need to constantly put the blank image back on, and test. There's about 60 installers for the 2016 run-time, at a minimum about 20 are needed. Which 20? Well install some, see if it works, install more, re-image, re-test, etc.
The second environment I was talking about was a normal Windows VM, where I can do this install, snapshot, test, etc, more easily. Once I have a good set of what I need to install I can move to the Pi and see if it works there too. I suspect at the end of this I can have an inno setup installer, that installs the runtime on the Pi.
Also I now have a video.
That is what we did with the boxed app. But this boxed app tool takes everything that is installed, and puts it in a exe that can access it all. Then, you can delete things one by one until it stops working. But this is after the installer, so it won't tell you what needs to be installed and what not. Not directly anyway.
Running a Pi image on a Windows QEMU VM isn't out of the question though.
This is how I did it years ago (but without a decent tutorial): Raspberry-Pi-Emulator-for-Windows-10/ . Not sure if it will scale to the W10 image.
Apparently, another way to do this is to run a Linux VM on Windows, and then the Pi image in a VM in the VM? how-to-run-raspberry-pi-desktop-on-windows-or-macos. Seems like a stretch (W10\x86>Linux\x86>W10\Arm).
BTW. It feels a bit like I'm exploiting your time and knowledge 😊. It is highly appreciated and I hope some of my input be useful.
@Hooovahh wrote:
Edit: Now that I think about it, NI has several platforms it deploys to for real-time that don't have SSE2, so the compiler must have an option somewhere to disable it. Even if it isn't used for Windows binaries.
SSE is an x86/x64 setting only.. So that simply doesn't apply to most real-time targets NI has. It is present since Pentium CPUs were introduced, so nowadays it is almost impossible to fid a PC that does not support SSE in one way or the other.
Your problem is that the RPi is really an ARM CPU and the LabVIEW Win32 application is executed inside a CPU emulation layer on the Windows system running on the RPi. Something like QEMU but the Microsoft version of it. This emulator seems to only implement the basic x86 CPU instructions and not the SSE (or the emulator doesn't implement the instruction to check for the SSE extension to be available in the correct way).
Okay one more update then I might be moving on to something else. I created an Autoit script that will look for NI installers, and install them one at a time silently. Basically a recursive search for MSI files. It also looks for EXEs running them silently assuming it is the Visual C++ runtime. The Autoit script, along with the build EXE is attached. Put it in a folder with the setup.exe, and instead of running setup.exe, run Install RTE.exe. Using this I was able to install the 2016 runtime with a single EXE. One of my favorite pieces of code is the Front Panel Publisher which allows for controlling a VI from a webpage using websockets. I ran it but Edge didn't support some functionality. So I installed Firefox and Chrome. Both eventually worked but ugh! With only 1GB of ram the system is constantly swapping to the drive, and I might be wrong but I think it is using the SD card. CPU speed was up to 1.5GHz and was mostly good, but memory and drive performance made it a pain. So summary time:
- You can install Windows 10 on Pi4.
- At the moment driver support is really bad. Most hardware doesn't work.
- Performance is not terrible, but also only responsive when very little is running.
- x86 applications are supported.
- But LabVIEW 2016 is the newest that will work due to SSE optimizations.
- Installing the RTE has to be done manually or with a script like the one attached.
- Overall 3/10. Avoid.
What are you trying to do? LabVIEW with Linx runs natively on the Rpi. But it is more like an embedded target running in its own chroot environment on the Rpi and has no local UI. LabVIEW for Linux which is the one that got installed on CentOS is an x86 (since 2016 only x64) compiled executable and won’t run as is on the ARM Rpi. It might be possible to make it tun with qemu but that puts you back at square one. Trying to run something like LabVIEW under a CPU emulator is very difficult. Trying to fight windmills is much easier and with more chances for success beyond a solution that is more than just to show off that it can be done! 😀
Every-time you change anything like LabVIEW version, used functionality and what else you can go back and try to figure out what needs to be installed. Hardware access is generally out of question as device drivers seldom can work within a CPU emulation layer.
So anything beyond built in TCP/IP is unlikely to work. That even includes potentially TLS support in the last LabVIEW versions.
