Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW for Linux on single board computers (e.g. Beaglebone)

Consider voting for the following idea on the LV Idea exchange. 

        http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-labview-everywhere-a-reality/idi-p/1994483


Peter
Message 21 of 34
(1,391 Views)

I just saw this video where the iOS "Data Dashboard" is presented.  Unfortunately, this App only acts as a "Display" (no real interaction with VIs).  But also in the video there's Jeff Kodosky one of the NI founders, playing with an iPad and doing some real LabVIEW programming on it.  As far as I'm concerned, iPads run on an Apple A6 processor based on ARMv7.  Does this mean that in the close future we can expect the programming and deployment of executables on devices running on ARM?

0 Kudos
Message 22 of 34
(1,391 Views)

The demo reminds me a little of LabVIEW for Lego Mindstorms. 

Not sure if they did this for the demo or not, but I once fooled a few people by running some remote desktop software on my little Nokia N810 and logging into a PC that'd I'd prepped specifically for the purpose.  Programming wasn't very easy.  But it was possible. 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 23 of 34
(1,391 Views)

Not likely.

What you saw Jeff Kodowsky playing with was an early version (probably pre-alpha stage) of an entirely different software project that uses the same LabVIEW style graphical symbols but works very differently internally. It is mostly a proof of concept how to get a programming environment like LabVIEW usefully operator friendly on a device which lacks any mouse pointer device, direct keyboard entry and all that kind of stuff like most tablets have now, which almost exclusively can be operated through a touch screen.

One of the features Jeff talks in there is a physics based engine which should help create reasonably layed out diagrams despite the very unprecise operator control through the touch panel. I doubt that the actual LabVIEW engine in there can do much more than a few basic LabVIEW primitives currently. If it ever gets integrated into LabVIEW in such a way that you can create executables for the tablets on other systems like a full LabVIEW development system, is probably still unknown by NI. And if it will resemble a real LabVIEW experience on tablets just as much. It's exciting that they do work on something like that, and it's likely that there might be some offering in the future that is something between Dashboard and real LabVIEW, but I would not hold my breath for it.

Rolf Kalbermatter
My Blog
0 Kudos
Message 24 of 34
(1,391 Views)

IMHO, tablets or smartphones used as remote desktop tools are not a nice solution. This is why i hope there's at least a very basic LabVIEW engine running on that iPad's processor. This would be a huge step on the development of portable embedded solutions implying data acquisition.  It would open a new world of portable laboratory/scientific solutions.

0 Kudos
Message 25 of 34
(1,391 Views)

One big problem of this which you shouldn't forget: LabVIEW without IO drivers is really more a toy than a useful programming environment. Interfacing to the platform TCP and UDP socket drivers is something fairly easily done. Porting VISA to the iOS or Android platform is likely a very different beast of burdon and in the case of iOS burdoned with additional Apple license issues. Dreaming of DAQmx on either of those platforms is probably going to stay a wet dream forever.

Rolf Kalbermatter
My Blog
0 Kudos
Message 26 of 34
(1,393 Views)

Just and idea: Intel Galileo or Quark. They are peintum-like dvices, so stock linux can be run on them, and regular LabView for Linux should do the trick. Althoug IO support or real-time would be still at early stages of support, as a generic embbeded PC it could work.

I got the idea rencentlry from a Support Specialist at NI, when I ask escentially the main question on this thread.

0 Kudos
Message 27 of 34
(1,393 Views)

For anyone interested in this stuff, check this new package out!

http://sine.ni.com/nips/cds/view/p/lang/en/nid/212478

https://www.labviewmakerhub.com/doku.php?id=blog:users:makerhub:2016-04-07-linx-3

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
0 Kudos
Message 28 of 34
(1,393 Views)

It better to use for this propose IDE for normal languages, such as Qt Creator (C/C++) or Lazarus (FreePascal).

0 Kudos
Message 29 of 34
(1,393 Views)

@rolfk wrote:

While it's understandable that you are disappointed the issue is actually a little different than what you think. The reason LabVIEW supports only embedded targets from NI out of the box is that there is a HUGE effort to create a LabVIEW environment to run on any specific embedded target.

Not quite. Of course, it takes a lot of effort to support a new CPU architecture, but once that's done, the rest isn't so much, especially not drivers, as that's already done in the kernel. (of course, on Linux, free kernel drivers are mandatory for any serious use).

 

Obviously, you shoud *NOT* try dumb things like directly passing through raw IO memory space to the FPGA to userland and play w/ proprietary libraries. Instead you should write proper kernel drivers for the few remaining devices (or hire some kernel hacker to do that) - and bring them to mainline. Of course using the existing kernel infrastructures like IIO, instead of inventing proprietary devices. Do that carefully, then you only have to do that once (we're not forced to stick w/ crappy vendor kernels). Then add proper hi-level bindings to LV.

 

If you're already at porting LV to a different architecture, target LLVM (basicly make LV compiler a LLVM compiler frontend), and then let the LLVM infrastructure do the rest - now you're pretty CPU agnostic. That's even pretty standard for cases where performance really matters, eg. GPUs. (yes: GPUs themselves running LLVM).

 

There are virtually 100ds of different ARM embedded targets (and quite a few other CPU families)

That's what the kernel is for. It provides a clean hw abstraction.

 

with many of them suporting several very different kinds of (RT) OSes.

One is enough: Linux. 

 

Each of these targets has a specific hardware device selection with many of them requiring their own specific device drivers that adapt to the OS of choice.

That's what the kernel community / bsp vendors are taking care of. 

 

Putting a LabVIEW system on such a hardware is anything but trivial and quite impossible for NI to do even for a few selected hardware targets.

Why so ? Because everything wildly twisted together and no proper abstraction layers ?

 

They did it with LabVIEW ARM Toolkit for a few (not using Linux but the Keil RT OS) and almost nobody is using it because it's quite expensive and of course not the HW and/or OS of their choice. 

Of course, nobody is seriously using Keil. It's horrible. They even fail to provide decent command line tools to drive fully automatic build processes (I doubt they ever heared of tools like make) and only support some very expensive game laucher OS'es. And their "RT OS" isn't much more than a bit scheduling and memory management - just a small piece of an real OS - even bootloaders offer more features. 

 

Who had that funny idea of targeting Keil in the first place ? (obviously cant be a sw engineer)

 

Installing LabVIEW on any of the not officially supported Linux x86 distributions is already quite a roulette game,

Yes, because they still refused to learn the basic lessons of GNU/Linux development and release engineering. Just look at the weird stuff in their .rpm's.

The worst of the worst is binary-only kernel modules - a really ridiculous idea to begin with. Linux was never designed to support that (and that's one of reasons why it's so superiour here). Just don't do that - it won't work. 

 

Summary: it's complicated, because NI folks makes it complicated.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 30 of 34
(1,276 Views)