Using LabVIEW in a Docker Container

[John80]

I was able to install the LabVIEW 2018 Runtime via an msi file that I ripped out of a Build Specification.

From powershell:

* run build.ps1 to build the docker image

* run run.ps1 to run the docker image

You have to have Docker running in Windows/HyperV mode.  This disables Oracle VirtualBox, which leaves me personally with the option of running this only from my laptop, otherwise I would have gotten a lot more done sooner!

https://github.com/JohnStratoudakis/LabVIEW_Docker

I was also unable to run any labview executable and to get any meaningful results.  I tried a few things, but that was only with regular vi's built in to executables.  Maybe I can write my own LabVIEW Command Line Interface that does rely on LabVIEW.exe being actually present on the machine...

[wiebe@CARYA]

Thanks for sharing your progress!

---

@John80 wrote: 

I was also unable to run any labview executable and to get any meaningful results.  I tried a few things, but that was only with regular vi's built in to executables. 

---

Could you elaborate? You can run VI's, but nothing meaningful? Not sure what you're trying to do, what results you get, or if my expectations are off.

If you install anything in Docker, I'd expect it to run the executable as it would under Windows?

---

@John80 wrote:

Maybe I can write my own LabVIEW Command Line Interface that does rely on LabVIEW.exe being actually present on the machine...

---

You mean one that doesn't rely on LabVIEW.exe? You've lost me there. Why'd you need a CLI?

[John80]

To make a long story short, docker is a pseudo-virtual machine that does not provide you with a graphical user interface.  Running a windows executable that relies or creates a GUI is not reliable.  Probably because it does not make sense and many Windows API calls would fail and crash the application. LabVIEW does not provide us (as far as I know) with a mechanism for generating an executable that does not create a GUI.  I thought this would have been solved with the CLI feature, but it has not.  The CLI requires that LabVIEW be installed on the target machine and I do not see a way to install LabVIEW on the target machine.

What I was expecting was a way to create a native Windows console application that can be called from the command line and can interact with the user via standard input and standard output.

My only thoughts now are to create one myself.

[wiebe@CARYA]

---

@John80 wrote:

To make a long story short, docker is a pseudo-virtual machine that does not provide you with a graphical user interface.  Running a windows executable that relies or creates a GUI is not reliable. 

---

Bummer. That is the only use case that makes sense for me.

---

@John80 wrote:

Probably because it does not make sense and many Windows API calls would fail and crash the application.

---

It does make sense from a user perspective. The fact that it's hard, well, I thought Docker was trying to solve that...

---

@John80 wrote:

 LabVIEW does not provide us (as far as I know) with a mechanism for generating an executable that does not create a GUI.  I thought this would have been solved with the CLI feature, but it has not.  The CLI requires that LabVIEW be installed on the target machine and I do not see a way to install LabVIEW on the target machine. 

---

I looked into this years ago when I wanted LabVIEW for Linux to run on a headless device. Back then LV needed a GUI, and I'm pretty sure that's still the case, and it won't change soon.

The CLI is just an add on, AFAIK it did not change anything about it.

The build in CLI requires LV, but there are ways to have a CLI gateway to a LabVIEW exe.

---

@John80 wrote:

What I was expecting was a way to create a native Windows console application that can be called from the command line and can interact with the user via standard input and standard output..

---

No, it's just a server listening for command line commands.

---

@John80 wrote:

My only thoughts now are to create one myself.

---

This has been done before. I've done it before, but I used .net, so I guess that won't be ideal in a Linux environment. Although I'm not sure what is... Some sort of dll interface is needed to get a CLI.

[jon_mcbee]

Have you come across this?  I am going to play around with getting a simple LabVIEW app with a C wrapper into a docker container.  Just tinkering.

[John80]

I have a feeling that what you posted would work.  

[wiebe@CARYA]

Back then I tried a dummy X Server (Xvfb or something). But I'm a Linux noob, so I failed. Not sure if that would work in this situation either.

Do GUI's work under Docker and Linux? Because Windows now has a Linux build in. It should run Linux applications with an XServer running under Windows, that might work as well in a Dockered Linux application.

It would be very inconvenient that LabVIEW for Linux is required...

[rdecarre11]

So I am going to add to this, but not specifically about trying to run LabVIEW applications in a docker image.

I, too, build on Jenkins and it has been pretty widely known that we would need a new VM for each version of LabVIEW (or even for the driver configurations like XNET, DAQmx, etc). I am hoping to be able to run multiple dockers on the same VM using https://hub.docker.com/r/jenkinsci/slave/ as a basis. The Jenkins Pipeline would be the thing that decides on which to execute. I think it's basically just a matter of how well LabVIEW and TestStand will behave when running inside these dockers, assuming I can get them in there at all.

I guess this is pretty similar to what we're talking about on this thread.

[John80]

So I spent some cycles on trying to run LabVIEW inside a Docker Container.  

I was able to install the LabVIEW runtime msi files:

• LV2018runtime.msi
• LV2018rtdnet.msi
• LV2018rteres.msi

I used the following Dockerfile commands to get this to work.  I also got these files by creating a LabVIEW .NET DLL installer.

RUN Start-Process msiexec.exe -ArgumentList '/i', 'C:\build\LV2018\LV2018runtime.msi', '/quiet', '/norestart' -NoNewWindow -Wait
RUN Start-Process msiexec.exe -ArgumentList '/i', 'C:\build\LV2018\LV2018rtdnet.msi', '/quiet', '/norestart' -NoNewWindow -Wait
RUN Start-Process msiexec.exe -ArgumentList '/i', 'C:\build\LV2018\lvrteres\LV2018rteres.msi', '/quiet', '/norestart' -NoNewWindow -Wait

And after a lot of issues, and trust me there are many with Docker for Windows I was able to get a coherent error that might be familiar to someone else who has ever distributed a LabVIEW application with just the runtime.

Please note, I have tried silently installing the LabVIEW runtime, the LabVIEW installer but they all fail.  One reason is that I cannot start the installer (usually the setup.exe) in silent mode because it is really under the hood a windows application and the RUN command does not wait for that application to start. 

Anyway, I'll keep trying more things and will post my code.  But long story short, I have a way to call in to the NI .NET DLL, but am not able to get it to work.  Some dependencies are missing.

Unhandled Exception: System.TypeInitializationException: The type initializer for 'InteropAssembly.LvClient' threw an exception. ---> NationalInstruments.LabVIEW.Interop.VIAssemblyException: Invalid LabVIEW Run-Time Engine.
   at NationalInstruments.LabVIEW.Interop.LVRuntime.CheckPrecondition(String lvRuntimeVersion, Boolean enableLoadLatestCompatibleRTE)
   at NationalInstruments.LabVIEW.Interop.LVRuntime..ctor(String[] entryPointNames, String lvClientAssemblyPath, String lvRuntimeVersion, Boolean enableLoadLatestCompatibleRTE)
   at InteropAssembly.LvClient..cctor()
   --- End of inner exception stack trace ---
   at InteropAssembly.LabVIEWExports.addNumbers(Int32 a, Int32 b)
   at csNFConsole461.Program.dotNetTest() in C:\work\git\LabVIEW_Docker\apps\csNFConsole461\Program.cs:line 45
   at csNFConsole461.Program.Main(String[] args) in C:\work\git\LabVIEW_Docker\apps\csNFConsole461\Program.cs:line 37

[Harlequinade]

I guess it starts with 

Invalid LabVIEW Run-Time Engine.

So make sure you have the correct bitness, 32 vs. 64 bits. Oh and I have struggled often with the dotNet dependencies. Like they changed the version at some point and you need to make sure you have that one installed. Perhaps look at: http://www.ni.com/product-documentation/14434/en/.