Hobbyist Toolkit

cancel
Showing results for 
Search instead for 
Did you mean: 

Creating LabVIEW GUI/executables to run independently on Arduino or Raspberry PI

As I understand from other posts, there appears to be no way to create a LabVIEW (Community Edition) executable with a GUI to deploy to a Raspberry Pi or Arduino. (Very disappointing.)

As a retired LabVIEW SW Engineer, I was interested using RPi as a hobby board to develop software programs to deploy to an RPi and run independent of the development environment. I cannot justify spending thousands of $$$ to buy the full LabVIEW Development Suite for a hobby.

 

Is there any inexpensive way around this?

0 Kudos
Message 1 of 6
(3,070 Views)

I am not sure why you would need the full LabVIEW Development Suite.  What are you referring to that is available there which is not available as part of the Community Edition?

 

Have you checked out this thread? https://forums.ni.com/t5/Hobbyist-Toolkit/GUI/m-p/4136915  If you want to do the HMI with LabVIEW then the G Development Software is the recommended solution.

 

Here is a presentation I gave on LabVIEW and Web Browser Based UIs - https://forums.ni.com/t5/North-Oakland-County-LabVIEW/User-Group-Meeting-May-5th-2021-LabVIEW-and-We...

 

Note that for Arduino you cannot run LabVIEW code headless so your HMI would be hosted where ever the LabVIEW code is running.

David Wilt
The New Standard LLC
Message 2 of 6
(3,053 Views)

You misunderstood the limitations. The deployed Raspberry Pi program has no GUI, even if you used the LabVIEW Professional version with the Linx Toolkit. This is a limitation of the ARM runtime engine use also for the NI ARM cRIO chassis. These chassis' have no built in display interface and are all meant to run as headless controllers. The LabVIEW for Linx Toolkit simply creates a virtual environment on the Raspberry Pi in the form of a chroot guest system that is compatible with the ARM architecture on the NI cRIO chassis in order to reuse the same compiled infrastructure that is also used for the ARM cRIO platform.

 

As such the deployed executable can't have a GUI, since the used LabVIEW runtime engine simply has no support to display any GUI, no matter if the underlaying hardware has a display adapter such as on the Raspberry Pi or the Beaglebone Black board.

 

The LabVIEW version for x64 cRIO chassis has (limited) GUI support built in but is still meant to usually run headless. It's capabilities are substantially limited to what you are used on Windows and its use has to compete with the real-time capabilities on those cRIO chassis.

 

The only way you could have direct GUI support on a LabVIEW for Raspberry Pi deployed executable would be if NI would specifically create a different runtime engine for GUI enabled ARM targets. Until NI creates any ARM based cRIO chassis that has built in GUI support, chances for that are pretty much exactly 0%.

 

What could you do? Well what is inexpensive for you? If you are willing to spend some of your time, you could consider an approach where you do the user interface for instance in a browser that communicates with your headless executable. It's not trivial and will take quite a bit of effort, but it's a possibility.

 

And as David already explained, the Linx toolkit does not allow you to deploy code to any other controller than Raspberry Pi and Beaglebone Black. It only allows to install a Linx based server based on a precompiled shared library that lets the Linx Toolkit communicate with it over serial or TCP/IP. Alternatively you can develop your own program for your Android controller in your own favorite Android IDE and then communicate over serial and TCP/IP with your own implemented protocol. 

Rolf Kalbermatter
My Blog
Message 3 of 6
(3,041 Views)

Perhaps I did misunderstand the Raspberry Pi(?) limitations.

 

Basically, what I want to do is create programs in LabVIEW and run them on a Raspberry Pi.

 

What you're saying is there's no LabVIEW compiler or runtime engine for Raspberry Pi.

 

In essence LabVIEW can only use Raspberry Pi as an interface to external hardware even though the Raspberry Pi can be configured to run as a Linux computer.

0 Kudos
Message 4 of 6
(2,984 Views)

Not quite. LabVIEW does create a executable for an ARM CPU, that is then deployed to the chroot environment INSIDE the Raspbian host. But that executable makes use of a LabVIEW runtime that is repurposed from the CompactRIO ARM platform, which does not have any GUI support.

So yes you have a LabVIEW executable that actually runs on the Raspi, even if you disconnect from your Windows host with the LabVIEW IDE, but this executable has NO built in UI of any sort. It runs in the dark, which is also the internal name for this runtime system, which the LabVIEW developers called lvdark mode.

It does whatever you programmed it to do but it can not display front panels on your Raspi display since the LabVIEW runtime used simply has no graphical IO support of any kind. The whole front panel is never drawn anywhere.

 

You still could have this executable provide an UI but you have to program that yourself by for instance implementing an HTML5 server, or providing a WebService interface, which LabVIEW also supports on the Raspberry Pi and develop a html solution that accesses this WebService interface.

 

For Arduino you are describing it correct. There is no runtime engine for Arduino (the Arduino hardware would be VERY taxed by trying to run a LabVIEW runtime engine). And therefore you can not deploy LabVIEW executables to an Arduino. You can however deploy a Linx runtime kernel to the Arduino which then provides an interface to the Arduino hardware, that can be accessed through the Linx library from another computer connected through TCP/IP or serial port to that Arduino.

Rolf Kalbermatter
My Blog
Message 5 of 6
(2,978 Views)

Well that's interesting...
So a compiled program running 'in the dark' could actually provide a rudimentary display using an LCD. Then using push button switches and/or a joystick it could display lines of text on the LCD that provide the user with information and allow the user to run sub-VIs. That would be a bit convoluted but workable.

 

Thanks for the info.

Message 6 of 6
(2,968 Views)