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).
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.
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.
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:
What you have done is really great.
LabVIEW runs natively on CentOS, and CentOS is available on Raspberry Pi. I'm wondering if anyone has gone down that road.
Old posts, but people have had success with LabVIEW on CentOS, no mention of CPU though.
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.
>What are you trying to do?
See about developing Home Edition LabVIEW on a cheap computer.
>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
I suppose this answers the question from your perspective, thank you.
I thought it was worth while asking because in contrast to what this NI site here says, Pentium 4 or later,
--as you wrote, you can effectively run in 'run-time' with Linx on ARM.
Thanks again for you comment.