LabVIEW
Labview for raspberry pi 3
@PHacke wrote:
>What are you trying to do?
See about developing Home Edition LabVIEW on a cheap computer.
In case it wasn't clear, I didn't try to be condescending but honestly asked this question. Usually with questions like this that are not motivated clearly, it is because of some specific thoughts that keep the person in a certain thought process, not allowing to see alternatives. So it is useful to understand the actual reason behind such questions.
>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.
It might sound like nitpicking, but for 64-bit execution you need at least a Pentium 4 G1 according to that document. This means SOME of the so called Prescott models and later. Earlier Pentium 4 such as Northwood, Willamette and Gallatine did not have the proper 64-bit execution support. Also all Pentium 4 Mobile CPUs did not have 64-bit support.
@PHacke wrote:
Worth mentioning, future looking, is that Mac is going to M1-type, which is ARM-based,
so NI will probably have to get on board with the migration.
In the interim, here are people trying to get LabVIEW working on it using a Windows VM.
True but Rosetta 2 (the Apple CPU emulation layer for x86_64) just works out of the box with a large Apple developer team behind it that had years of experience with Rosetta 1 to emulate a PPC CPU on x86 last time they did a platform technology switch. And even that does not work in kernel space, so no DAQmx. Ni488 or whatever on such a machine.
But LabVIEW for ARM Macs will require Mac OSX to run on simply because the entire platform interface is directly talking to the OS layer independent of the CPU it runs on. The CPU is mainly important for the compiler portion, which of course has to match the underlaying system too.No dice in trying to load that on a Raspberry Pi, and don’t forget resources. The Raspberry Pi would break badly through its knees when loaded with a full development system like you install on the Mac or Windows, so even if the Mac M1 version of a still hypothetical LabVIEW version could be put on the Raspberry Pi, which you can’t’, the development experience would be painful if it even does more than stuttering.
It’s not that NI can’t do an ARM native LabVIEW version. They have that at least for a runtime for their ARM based realtime devices which got reused for the Linx runtimes for Raspberry PI and Beaglebone Black solution. But just because something is technically possible does not mean that it gets done. NI is a stock market traded company and such things usually only get done if technical management can convince the commercial management that there is a commercial benefit of some sorts in it. A full development version for Raspberry Pi would cost quite a bit of money to develop, build, test, and distribute, with what revenue to offset that? Virtually none except maybe the good karma feeling, and while individuals may sometimes care about such a feeling, the stock market as a whole is very indifferent to that.. No potential gain, how overhyped it may be, means simply no available funds. And LabVIEW for Rasberry Pi is very hard to hype in a way that could interest anybody on wallstreet or other similar places. Leave that to AI and quantum technology which are currently a good way to raise money for totally useless projects if not to simply steal money sometimes 😀.
@PHacke wrote:
>True but Rosetta 2 (the Apple CPU emulation layer for x86_64)
very interesting.
Are you saying LabVIEW for Mac is on Rosetta 2?
Any x86-64 application you try to run on an ARM Mac will in fact be executed inside Rosetta 2. And yes there have been people who have got it to work on an M1 Mac. Although as explained, no kernel driver support, so outside of native TCP/IP nodes you can pretty much forget to talk to any other hardware from such a LabVIEW installation.
There were trouble to get LabVIEW for Mac to startup on any Mac with the latest MacOS 11. That had nothing to do with if it was an ARM or x64 Mac but with much tighter security requirements for executables and some graphic layer optimizations that could crash a process when it did certain graphic primitives in a certain order. And Mac OS 11 had pretty much removed all provisions to allow "unsecure" apps to be executed in any way unless you are willing to install special developer build kernels. Most of these issues were supposedly fixed with LabVIEW 2020 SP1.
Still there is some expectations from the user base to get a native Mac ARM version of LabVIEW. And I believe some people at NI are quite receptive to that idea even if it makes commercially maybe not as much sense. LabVIEW originated on the Mac and in a few years from now all new Macs will be ARM based, so not supporting that would be a little like disavowing its own roots.
Search LabVIEW like a graph! 