Reference Design Content

cancel
Showing results for 
Search instead for 
Did you mean: 

Wiresmith Technology: LabVIEW Command Line Interface (CLI)

A proxy mechanism to allow LabVIEW programs to easily write out to the command line.

 

Libary and component shared by Wiresmith Technology.

 

 

Source Code and Documentation:  https://github.com/JamesMc86/LabVIEW-CLI

 

CLI.png

 

Questions and comments about the code itself, should be posted to the Github repository of the code: https://github.com/JamesMc86/LabVIEW-CLI/issues

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
Comments
JoeWork
Member
Member
on

The link to your source code doesn't work.  It appears to have added an extra http to the link.

Christian_L
Active Participant
Active Participant
on

Thanks. It has been fixed.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
chinghwayu
Member
Member
on

I tried this but it looks like there's a bug passing command line arguments to LabVIEW. For example:

"c:\Program Files (x86)\Wiresmith Technology\LabVIEW CLI\labview-cli.exe" "C:\Documents\GitHub\LabVIEW-CLI\LabVIEW Source\CLI Demo.vi" -- "This is a test"

Doesn't pass "This is a test" as a single argument. Instead, it passed each word as a separate argument.

CLI Demo.PNG

James_McN
Active Participant Active Participant
Active Participant
on

Yeah that was a silly omission. I'll take a look at it over the next couple of days!

Cheers,

James

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
James_McN
Active Participant Active Participant
Active Participant
on

I've put a fix in and you can find it in the v1.1 release on github (https://github.com/JamesMc86/LabVIEW-CLI/releases/tag/v1.1.0-beta)

Hope that works for you, let me know how you get on!

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
chinghwayu
Member
Member
on

Thanks for the quick turnaounnd! Looks like it's working. I've got some ideas to put this into good use and will try to update with some details if it works out.

endeavor
Member
Member
on

Hello James,

thanks for sharing this awesome tool!

I'm having an issue with running a VI, namely labview-cli is only able to launch LabVIEW and open the VI but not to start it. If I run it manually afterwards it works fine, i.e. can communicate etc.

I'm using LabVIEW 2014 on a 32-bit machine. My command string looks like this:

"C:\Program Files\LabVIEW-CLI\labview-cli.exe"  -v --lv-exe "C:\Program Files\National Instruments\LabVIEW 2014\LabVIEW.exe" "C:\...\LabVIEW Source\CLI Demo.vi" -- "This is a test"

Few more observations which can be useful (or useless):

  • the default LabVIEW path won't work for 32-bit OS
  • in case path to the VI is incorrect, no error will occur and labview-cli will be waiting for connection; however if you make a typo in the VI extension, LV will immediately tell you that it's not supported even if the VI doesn't exist at all
James_McN
Active Participant Active Participant
Active Participant
on

Hi,


Thanks for giving it a go. You are correct about the VI not running immediately. The way I have worked with this is to set the VI to run when opened in the VI execution properties, this is the best way to get autorun behaviour from the command line. Anything more needs VI server which is a much bigger job!

I'm pleased to say some of your other feedback is being addressed. rose-a on github has created the code to get the exe location just from the version number which makes it much more friendly. This code is on github at the minute and I will build a release once a few more items are in.

As you can guess from the other I do some basic extension checking (to decide whether to launch as an executable or vi). We can probably add some checking for validity as well

Thanks again!

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
endeavor
Member
Member
on

Thanks for the explanation. I've set it to Run when opened (this option wasn't checked before) and naturally it works. Cheap and smart!

Great to know you're working on improvements, although the issues I've noticed so far are kind of minor comparing to what the tool brings to those who are excited about Jenkins or any other CI software. Thank you and everyone who's involved, your work is highly appreciated.

James_McN
Active Participant Active Participant
Active Participant
on

There are some excellent improvements now posted on github. I highly recommend the latest version which fixes most of the problems reported and some others.

Main great improvement is auto-detection of LabVIEW install paths as well as general robustness. Download it at https://github.com/JamesMc86/LabVIEW-CLI/releases/tag/v1.3.0

(P.S. most of this was implemented by rose-a so thank him, beauty of open source at work!)

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
joerg.hampel
Active Participant Active Participant
Active Participant
on

James,

 

just wanted to leave a note to let you know how well your tool works with my Gitlab CI. Releasing my software fully-automated as of now!

 

V1.4.0 really "kills it" 😉 😉




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


MattP
NI Employee (retired)
on

I have a set of build steps, with accompanying groovy scripts, for this tool that I posted here: http://forums.ni.com/t5/Reference-Design-Content/Common-Continuous-Integration-Steps-for-LabVIEW-Com...

 

Hopefully can save others some time.

Cheers,

Matt Pollock
National Instruments
mattyG
Member
Member
on

James, Thank you for sharing this tool!

 

I am calling a compiled Labview executable with the Labview-CLI tool. (ex: labview-cli myApp.exe -- myParameter)

 

It works perfectly on a machine that has both the Labview Runtime and any version of Labview development environment. Unfortunately, it does not work on a computer that has only the Runtime Engine installed. I get this error "No LabVIEW.exe found..."

The problem is the following. Since I am calling an executable there is no need to check for the installed Labview versions and for LabVIEW.exe. This should be skipped when the launch program is an exe.

CilinoCirrus
Member
Member
on

Was almost exactly what i needed. In my case, i'm trying to execute vi for post-install and pre-uninstall from NI Package manager. I need to be able to pass in command line arguments per ni package i'm installing \ uninstalling. However, once command line parameters are passed to the labview.exe, you cannot change the parameters on subsequent invocation of the "App.Args" without first shutting down and restarting the labview.exe. Shutting down and restarting labview for each NI Package action would take a significant amount of time and is prone to hanging. For example if when you attempt to start labview programmatically and are prompted with the "LabVIEW didn't shut down correctly. Would you like to recover your files?" dialog, that will hang your installation without user intervention.

 

Also in order to execute a post install \ pre uninstall step, the command line has to return to ni package manager. I don't see a way of terminating the CLI per command which would effectively hang an installation.

 

If these two features could be added (ability to pass in cmd line parameters without restarting labview, ability to have CLI return) then I wouldn't have needed to roll my own system :(. In my case I had to 

1. Create an executable that starts a TCP listener. The executable receives (via command line arguments) the version and bitness of the labview executable you'd like to launch.

2. The executable launches a Client VI in the version of LabVIEW passed to the exe. The client VI connects to the executable.

3. The executable passes all command line parameters to the client vi. One of those parameters is "Target VI". The target is the actual vi you would like to execute. The vi can be executed synchronously or asynchronously depending on a command line parameter.

4. Once the client completes its task, it terminates and sends the shutdown command to the executable which terminates. The exe does NOT send any outputs back to NI Package manager (something I'd like to solve).

5. Upon reinvocation of the exe new command line parameters can be passed to the exe which can then pass those parameters into a vi in an ALREADY running labview version, thereby preventing the restart from being required. If I get Cirrus Logic's permission, I intend on posting this code via NI Package and VI Package.

James_McN
Active Participant Active Participant
Active Participant
on

Grr still don't seem to be getting notifications for this thread! If it is an immediate issue then you can create one on github: https://github.com/JamesMc86/LabVIEW-CLI/issues

 

Thanks for the feedback and potentially sharing your work. This is indeed a pain with this tool at the minute and will be interested to see how you get around it.

 

I would be keen to simplify and have C# pass the arguments as an initial message once the TCP link has been created. This will then work whether calling into the IDE or a built executable. The problem is knowing what port to connect on. We can fix it - but then limiting to one LabVIEW CLI program at a time.

 

For the built executable this is less of an issue. For the LabVIEW IDE your concept is a good way to go. Another that has been discussed https://github.com/JamesMc86/LabVIEW-CLI/issues/30 which is to use the NI service locator. I'm preferrring this approach over having another proxy service, but I haven't had the time to work through all caveats yet (mainly about handling launching the same VI in multiple versions or the same version of LabVIEW, but also handling where the intialise might be in a dynamically launched VI, can it correctly identify the launched VI name to get it's port number)


Sorry, just braindumping on this topic a bit! It's something I'm really keen to get to (but having a young baby at home is getting in the way at the minute!)

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
FredCirr
Member
Member
on

I have a problem with the LabVIEW-CLI interface, that I don't seem to get around. I run a build of our, rather large, project. The MiniBuilder VI (attached).

Using the --kill command, I mostly get a LabVIEW crash report and "Error -1" in the command prompt. The build, though, is successfull and the builder VI exits without errors..
Running without --kill, I cannot go to the next stage in our build process, since LabVIEW is running.

 

Any ideas of what can cause this? Or good work-arounds?

 

labview-cli --kill --lv-ver 2016 "<path>\MiniBuilder.vi" -- "<path>\<project name> EXE.lvproj" "<build spec name>"

 

Edit: The output in the command prompt is:

Forcing LabVIEW to terminate...
LabVIEW exited with code -1 

FredCirr
Member
Member
on

I don't know if this is purely a LabVIEW-CLI question or if it also concerns Jenkins. But I can get the build running by calling my builder vi from the command prompt through LabVIEW-CLI and I never get an error.

But, if I call the same VI from Jenkins, I most of the times get a read error:

Read Error
: Incorrect Read of Length Bytes
Since the network stream will be out of sync the application will now exit.
LabVIEW exited with code 1

Looking at the C# code I think the error is caused by not getting any payload in the TCP read. But why should there be a difference in that when called from Jenkins?

I am able to write to std-out before it happens. It seems the read error is occuring when calling the NI AppBuilder Build.vi

 

James_McN
Active Participant Active Participant
Active Participant
on

So for your first question - is this then causing other issues?

 

We are literally killing the LabVIEW process in this case - just like you used task manager end process so it may not always be smooth! If you believe it is causing problems then you can use exit LabVIEW in your build VI and try it this way - it isn't perfect (for example save dialogs might be an issue) but it is a bit nicer.

 

The other problem is with the tcp read as you say and has me a bit stumped right now. It means we didn't read 4 bytes (for a length) but I think it also means there isn't a timeout since that would cause an exception. What version are you using so I can try and think of some way to test this?

 

Cheers,

James

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
FredCirr
Member
Member
on

The first issue with killing LabVIEW, I experienced that when LabVIEW wasn't killed the hard way from the LabVIEW_CLI.exe but rather that LabVIEW tried to close gracefully first. Sometimes I got the prompt asking me to save changes etc. But, I added some code in my builder VI to handle the kill the evil way and it seems to have done the trick *knock on wood*.

 

The other issue gets me more than confused too...

I'm using LabVIEW-CLI version 1.5.3.13 in LabVIEW 2016. The builder is coded on my Windows 10 machine. And the server is running a Win 7 machine.

FredCirr
Member
Member
on

I thought I'd add my solution to help others that might encounter the same error.

 The issue seems to have been that once in a while LabVIEW wanted to recover after killing LabVIEW. Unchecking "Prompt to investigate internal warnings or errors on startup" seems to have done the trick!

 

Option.png

 

Gopi_123
Member
Member
on

Hi,

 

Two months back, we started LabVIEW Jenkins CI automation. Now currently we running into an issue.

 

What happening is the the following:

1. I trigger the build and the source update via AccuRev(No problem).

2.Build.bat executes, it is hanging there only until we abort. But it is working fine in the local server.

Yesterday we changed the Jenkins user account, after that it worked fine for two builds and then again the same above issue came back, it is hanging in Jenkins, but it working in the windows server.

 

I observed that, when I build locally in the server in the the task manager LabVIEW use 25% CPU and  10 lakh kb memory, but when I trigger throw Jenkins at one point CPU % went to 0 and memory is hanging 1 ***** digit KB.

 

It would be great, if you can help on this. we get stucked her. Please help us.

Bhargavi_1
Member
Member
on

Hi @FredCirr,

 

I am facing the same error as you mentioned in the above message. For reference I am reproducing it here

Read Error
: Incorrect Read of Length Bytes
Since the network stream will be out of sync the application will now exit.
LabVIEW exited with code 1

I have tried restarting Jenkins and the PC as well. But this didn't solve the issue. Could you please let me know if this issue is solved?

 

Thanks in advance!

Bhargavi Gowri.

 

piZviZ
Member
Member
on

piZviZ_0-1591166281229.png

I am getting this error when I run this CLI Demo.vi

Is there any configuration require or require to open this file from command line ?

 

joerg.hampel
Active Participant Active Participant
Active Participant
on

piZviZ, that VI is indeed supposed to be called from the command line via g-cli. If you install the latest version (v2.3.0) the VI will have a comment with instructions on its front panel:

Bildschirmfoto 2020-06-03 um 20.23.51.png




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


piZviZ
Member
Member
on

Hi Joerg,

 

I am getting this error while executing commands.

piZviZ_0-1591685257397.png

 

joerg.hampel
Active Participant Active Participant
Active Participant
on

The error message indicates that the g-cli executable itself can't be found. I guess there are two possible reasons:

- the MSI package was not installed 

- something went wrong during the installation and the path to g-cli is not set

 

Can you verify that the g-cli.exe is actually installed on your system (eg at C:\Program Files\G-CLI\g-cli.exe), and that the installation directory of G-CLI is part of your path variable (in a cmd prompt, enter "echo %PATH%" and look for g-cli).

 

Maybe the easiest way would be to reinstall g-cli via VIPM?




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Contributors