Showing results for 
Search instead for 
Did you mean: 

Using LabVIEW in a Docker Container

Hello all,

This is a question of curiosity - has anyone tried (is it even possible??) to run LabVIEW in a Docker container?


0 Kudos
Message 1 of 22

Hi cirrusio,


Can you explain what a Docker container is? Additionally, what are you trying to accomplish by doing so?



Tyler C.
Technical Support Engineering
National Instruments
0 Kudos
Message 2 of 22

So, this question was well fleshed out before I sent it.  Basically here is the gist - I run on a non-enterprise linux distro (Solus).  Since all we have are the binaries targeted for RHEL based distros (i.e. Scientific and CentOS), Windows or Mac, I need virtualization in order to run LabVIEW.  Currently, I have a bunch of VMs that I use to run different versions of LV.  The problem with this is they are pretty heavy - they virtualize everything down to the hardware and sit on top of the OS. If possible, I would love to take advantages of other virtualization technologies that don't have the foot print or the resource usage a full VM does.


There are lighter weight virtualization technologies, such as containers, but I think Docker is not what I am looking for.  For running on Linux, Linux containers (LXC) might work.  But I am still not sure.  Would love to hear if anyone has an interesting solution that is not as hefty as a straight up virtual machine.

0 Kudos
Message 3 of 22

We (our company, not me personally) have made a few attempts with Docker under Windows. I don't think they where successful so far. The "build in" Linux under Windows will probably help a bit, but we haven't tried it since it was introduced.


I've done this myself for LV7, but I used a legacy program that seems to completely ruin Windows 10 when it's used. I used it under a WinXP VM, and that worked OK-ish. But since it's already obsolete, I hardly consider it a solution...


If you have a solution, I'd be very happy to hear it.

0 Kudos
Message 4 of 22

I'm trying to figure this out right now.  Am waiting for the 2018 runtime installer to come out this weekend so I can make a new stab at it.


Basically what I am trying to do is to install the LabVIEW 2018 runtime inside a Docker for Windows (not linux) and then to run a program via the Command Line Interface.


So far I have been having trouble running the LabVIEW 2017 installer, I have tried all the silent options but nothing has worked so far.  The thing is that Docker does not support applications that have user interfaces, so if the installer was built as a Windows Application and not as a Console Application, even if it does not show a user interface it may still fail to work under Docker.


you can follow my work here:


(So far it downloads and installs python and runs a simple python script)


0 Kudos
Message 5 of 22

If I've got this correct, basically you're asking has anyone run LabVIEW successfully on a Virtual Machine (and a 'docker' is a specially built VM which yields performance enhancements due to the OS it runs on)?


- I've run LabVIEW successfully on a VM. however not all of LabVIEW will run on a VM correctly. The Vision toolkit for example, will not activate if you try and run it on a VM. ( - a total pain if you are trying to support certain customers who have specific PC setup needs and you have to rebuild a real PC from scratch every time you need to answer a simple question or release some code for them!)



CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 6 of 22



remember, docker is not a virtual machine, it behaves like one but has some key differences - a docker container uses a special api to access certain services from the operating system

0 Kudos
Message 7 of 22

@James - so the reason I originally asked this is that I use linux as my daily driver and did not want to run LV in a VM (although this is exactly what I do now).  VM's are pretty heavy - they virtualize the entire hardware stack.  This means that the VM itself contains a lot of stuff that I don't need and has a large footprint.  I would like to strip away this and just have a container that has the bare minimum to run LV.  

This has other implications for standard software development practices that I won't go into here...

0 Kudos
Message 8 of 22

I've never run LabView in a Docker or other container, but I am interested in this topic.


What I am very familiar with is installing and running LabView (for Windows) without a user interface on VMs (either via VMWare or AWS EC2). Here are a few tasks I do regularly:


Build Application Using Jenkins

I build our application using Jenkins. The build machine is a Windows VM that has LabView installed and configured with the various toolkits and packages (via VIPM) required by the application. Jenkins is installed and runs as SYSTEM, which I am am not please about, but Jenkins routinely writes data to its installation directory in \Program Files and I was not able to get it to work under an unprivileged account. 


The least-common denominator way to build under Jenkins for Windows is to run a batch file to run the build, so that's what I do: one batch file to run Caraya unit tests and one to do the build itself. The batch files look like this (being the general way to run a specific VI in the development environment from the command line.) 

pushd {working directory}
start "fake title" /b /i /wait "C:\Program Files\National Instruments\LabVIEW 2017\LabVIEW.exe" "Project.lvproj" ""

Note that you need to have "" set to run automatically when opened; otherwise it will just open in your UI-free world and sit there waiting for you to click the run button. (You can open it for editing in your development environment without running it by opening the project first.) The "start" command may not be necessary.


Overall this works pretty well, but there are some annoyances. The first is that if you commit broken code (e.g. missing a VI) or leave any suspend-when-calleds active, LabView will throw up a dialog box, which you of course will never see. (You'll just wonder why the build is taking so long!) It would be nice to have LabView just exit with an error if dependencies aren't satisfied but I don't know of a way to force that. The second is that I have never succeeded in getting Jenkins to capture stdout during the build although it works fine if I run commands like the above from cmd.exe. But overall it's nice to have Jenkins checking out the code, pushing it to AWS S3 etc.


Programmatic Installation

I've never installed LabView itself from the command line, but I routinely automate installation of built applications, including the LabView runtime engine, by running the setup.exe program generated by the LabView application builder. Another batch file:

pushd {working directory}
.\setup.exe /qb /AcceptLicenses yes

You need the AcceptLicenses flag or you'll get stuck at another dialog box.


Running Headless

I run multiple headless instances of our application as Windows Services using FireDaemon. To pass configuration data, set environment variables in FireDaemon and read them using WinAPI (easy). The only trick here in running multiple instances of an application is that you need to create an .ini file called {My Application Name}.ini containing these settings (from LabView.ini):

[My Application Name]

If you don't want to run as a Windows Service, you can just fire up your application directly from cmd.exe or whatever:

"\Program Files\My Dir\My Application.exe"

but then it will quit if you close the shell or log out.


I know none of these use cases really reflect what you are trying to do, but I wanted to at least give some hope that one can run LabView without a UI, and let you see the use case I am interested in, e.g. running the application in a (Windows) Docker image instead of a Windows VM. I'm also interested in running LabView for Linux in a Docker image as well, although that would be a bit more work.

One aspect of your use case I don't understand is the desire to run the development environment (vs compiled app) inside a container. Don't you need a UI in that case?




Message 9 of 22

John80, I'm curious if you have made any more progress with this.

0 Kudos
Message 10 of 22