LabVIEW
Labview for raspberry pi 3
Oh yeah that's pretty close to what I bought for $80 (half the cost of the processor that died which needed to be replaced). My processors have a TDP about half Linus's, and processor speed is about 10% less, same socket. Max ram on my system is 32GB, and other equally old components are cheap. Sorry didn't mean to derail.
I wasn't claiming you couldn't make the LabVIEW IDE run on a Raspberry Pi (or a 10 year old Laptop), just that it wouldn't be a pretty experience and that that is more than enough reason for NI to not even think about investing a single dime in that idea, aside from the fact that such large scale development for LabVIEW CG is basically out of question anyways now. And LabVIEW NXG being purely Windows only thanks to its huge .Net foothold, makes this not a single bit more likely to happen for NXG. On the other hand try to run LabVIEW 5 or even 7.1.1 on a current computer and you have barely time to blink your eyes before everything is up and running! 😁
Back in the days I was actually working on getting LabVIEW to run on Wine, not because it was a good idea in terms of usability, but just for the fun of trying to get it to work. It even resulted in a few patches for the Wine project on the side. When it did finally work, it was anything but pretty to use and the rumors of LabVIEW for Linux, while not officially released by NI at that time, were floating around in the unofficial talks.
The slowing down of processor performance improvement has many reasons. That goes from the inherent overhead of managing more and more complex systems (a standard CPU now is very complex compared to a whole computer system 25 years ago), to improved security concerns (side channel attacks were something most people including experts wouldn't even have dreamed of 25 years ago), and the fact that we are slowly approaching the limits of what is physically possible. Every improvement we do now costs exponentially more to achieve, compared to the same percentage grow 25 years ago. At the same time software gets more and more complex too and expectations as well and that easily eats up all the performance improvement we can achieve. It's a rats race really. 😀
There have been tests to use RPi as desktop replacements, and it's just not up to it.
I agree with Rolf, running LabVIEW development environment will not be practical (I would like to see it though).
Maybe (a big one), LabVIEW 4 will run smooth? Or maybe even 5, 6 or 7? That would be 'neat', but not much more than that. I don't really want to go back to LabVIEW as it was 10-20 years ago.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
There have been tests to use RPi as desktop replacements, and it's just not up to it.
I'm not trying to be argumentative with you or Rolf, I just am not a fan of blanket statements like this. I think the Pi4 is a desktop replacement for some. The other blanket statement from Rolf that I didn't agree with was this:
LabVIEW IDE native on Rasberry PI hardware or similar will never happen.
And honestly it depends on your definition of "native". I'm sure he was stating there wouldn't be an ARM based LabVIEW IDE, and my brain didn't go there. I took that to mean the LabVIEW IDE will not run on the Pi without some kind of VM or emulation needed by the user. I didn't immediately consider the Win32 compatibility layer on the Windows 10 IOT to fall into that category but on a software level it clearly does. That's more or less why I replied with "LOOK LOOK IT IS POSSIBLE!", when that wasn't what he meant.
I hope we can all agree the experience wouldn't be great (but likely is possible especially for <7.x), and it isn't something people should try to do for any other reason than a curiosity. A curiosity I am quite curious to see.
@Hooovahh wrote:
wiebe@CARYA wrote:
There have been tests to use RPi as desktop replacements, and it's just not up to it.
I'm not trying to be argumentative with you or Rolf, I just am not a fan of blanket statements like this. I think the Pi4 is a desktop replacement for some.
Of course it depends on what you do with the desktop. If you lower the standard enough, it will suffice.
The Win32 compatibility layer will slow everything down by another order of magnitude. Even notepad runs slow under Win32 compatibility layer, from the demos I've seen.
I don't think there even is an argument here. We're saying the same thing here. It won't be pleasant iff it would work.
@Hooovahh wrote:I hope we can all agree the experience wouldn't be great (but likely is possible especially for <7.x), and it isn't something people should try to do for any other reason than a curiosity. A curiosity I am quite curious to see.
There is a challenge right there, so I'm curious too.
I'm stuck on getting even a LabVIEW executable to work on Win IoT. The Windows IoT download problem stopped me completely. I don't understand why MS doesn't simply release it. Apparently, registering as "insider" isn't enough, you also need to 'upgrade' windows to the 'insider' edition. At least that is the only reason I can think of. If someone knows of an image online, I might give it a time. Although it's jag shaving. I'll (also) have no time to look into Linx, and that fits my (non-existing) needs better for now.
So I have progress on this, but it is still all just in the name of experimenting and should not be used for anything other than that.
So I bought a Pi4 4GB to play with at home since...well I'm going to be home a lot lately. I first started playing with Linx and had some success and wanted to move on to Windows 10. Using instructions found here I was able to install Windows 10. It was a pain and has major limitations at the moment. Most notably is no USB-A port works, just USB-C. So through that port is a USB hub with a wireless keyboard/mouse, and a USB drive to boot to (SSD). Another major limitation is at the moment it is limited to 1GB of system memory. Oh and the built in network port doesn't work yet, but another one may.
Anyway I'm not interested in that, I'm interested in if you can install the LabVIEW runtime and what is possible. I was thinking of making a new post for this, but honestly I didn't want to make a new post which might look like a how-to when really this is just intended to describe what I did and some issues.
So once in Windows how is it? Well mostly responsive. Once idle the CPU usage is around 5%, with memory usage being at 80% at the lowest, usually it is higher (remember this is software limited to 1GB at the moment). Nothing feels snappy, but applications do launch, windows resize, and things generally work well just slow. Not terrible not great, but it is a fresh minimal install of Windows.
As for the LabVIEW part. I started with a LabVIEW 2018 EXE and installer. Running the installer returns an error "The Windows Installer engine is corrupt. To attempt to resolve this issue, please register the engine by running regsvr32.exe on msi.dll". So I went into the bin folder, and from there just started running all the installers. These are the sub-components in the run-time engine. After running about half of them I tried my EXE and it ran...but said that SSE instructions were enabled and that the EXE couldn't run. I tried turning off SSE in the project and rebuilding but it didn't work. The checkbox was removed seemingly in 2017. I opened 2015, unchecked the box, and saw how the lvproj file was edited and tried putting that in it to see if the setting was removed but the functionality was still there. No dice. Here is what was added to the project file, under the My Computer >> My Application section.
<Property Name="Bld_compilerOptLevel" Type="Int">0</Property>
So I tried 2015 with the SSE disabled, made the EXE made the installer, manually installed the RTE, and...my EXE ran! It is just a while loop and measuring the loop time. Here are some images. I have a video but Google is being difficult. This shows a loop rate of 30uS, with quite high jitter. I just tried 2017 SP1 with the line added for compiler optimization and it still wouldn't run. I don't have 2017 SP0 to play with so I'll be trying 2016 next.
That's a great base line to go from!
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...
It would be a lot of work to test them (I suppose you have to start with a clean image each and every time?) but then the correct option might fix the problem just like that!
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.
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.
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.
