jamesmc86 / g-cli Goto Github PK

Right now it makes it look like LabVIEW has crashed.

I have tried to cancel a jenkins job where LabVIEW was non-responsive.

I see that the LabVIEW thread is killed but something is hanging on in the application.

Log output:

Launching Program:
C:\Program Files (x86)\National Instruments\LabVIEW 2015\LabVIEW.exe "C:\Users\Public\Documents\National Instruments\LV-CLI Common Steps\steps\run-vi-tester.vi" -- -p:62908 "Monitor Software.lvproj" "test_results" "${WORKSPACE}"

LabVIEW started, process ID is 1152

Waiting for connection on port 62908

Aborted by James McNally

Sending interrupt signal to process

Click here to forcibly terminate running steps

LabVIEW exiting...

LabVIEW terminated unexpectedly!`

We should have an example installed so we can provide a path to see it and then perhaps an example for the command line applciation as well.

As a tool developer I want to make it as easy as possible to call my tools.

One way we can tool this is to have a CLI Tools directory. If we don't find a VI locally, we can search here.

That way, as a developer, I can install a launcher into this directory for my-tool.vi and then users can just type labview-cli my-tool.vi to launch it.

A future evolution might be to have LabVIEW specific folders to avoid compilations but we will start simple.

On Windows 10 after running the msi installer from release LabVIEW-CLI-1.5.3, I opened the CLI Demo in LabVIEW 2018 and noticed that the Exit with Error Cluster element doesn't accept the error code parameter. I also noticed that its icon looks odd. Any help on this will be appreciated.

James, I thought that I should take our email conversation here so it's available for others seeing a similar behavior:

C:\Multi-Runner\builds\df1e0484\0\hampel-soft\cmd
Unhandled Exception: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: size
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at LabVIEW_CLI.lvComms.readMessage()
   at LabVIEW_CLI.Program.Main(String[] args)
ERROR: Job failed: exit status 3762504530

It does find it in the end but it is an annoyance. If it can be fixed it should be considered.

labview-cli.exe exits with return code "0" on reporting a "Read Error", which suggests to a CI system that the build was successful.

only the "Help Screen" dummy text gets displayed if you type labview-cli --help

If I call my build VIs manually, either directly from the development environment or via my build GUI, the "Start CLI Interface.vi" throws an error (scan from string fails because list of parameters is empty). What I would like to be able to do is tell the CLI interface that it should just ignore all following calls and not throw any errors, so I don't have to disable all of the occurances of the "Write String.vi"s all over my code.

Currently the packages directory is checked in BUT all dlls are ignored which causes issues if we nuget restore later.

Need to make it consistent - best practice would be to remove whole packages folder.

I get issues with connections. With the default we wait for a connection for ever which locks up the jenkins build process. The default for the timeout should be set to perhaps 10 or 60 seconds to prevent this.

Need to handle:

• LabVIEW is open but VI isn't - currently it does open but we lose our process reference so CLI stops prematurely.
• VI is already open in LabVIEW - Not sure if this is detectable or handleable. If it can be, a suitable warning should be given.

New to LabVIEW-CLI. I'm following a getting started guide and got stuck trying to run the echo test example with 2017 64 bits.

The error returns:

LabVIEW version "2017 64bit" not found!
Available LabVIEW versions are:
2016 f2, 32bit
2017, 32bit
2016 f2, 32bit
2017, 32bit

On the other hand, I can successfully run the echo example in 32 bits.

Launch-VI is resolved to something stupid if left out (ie. if you just type labview-cli -v)

Maybe one could use the Lists and Arrays features of the CommandLineParser lib to parse the whole argument string (especially Launch-VI and LV-Arguments) with the library methods (see https://github.com/gsscoder/commandline/wiki/Mapping-Properties-To-Options).

This would also help generating a proper help screen.

Please add newest CLI version to releases. I saw that kill option is provided but executable with that functionality is missing.

When trying to launch a VI in the 64-bit version of LabVIEW, I get the following text.

LabVIEW version "2016 64bit" not found! Available LabVIEW versions are: 2016 f5, 32bit 2016 f5, 32bit

One of those 2016 32 bits should be the 64 bit version!

There is an API that will allow us to detect if LabVIEW is already running but it appears it will require our application to be 64bit in order to support it.

Questions are:

1. Do we mind the application being 64bit? I think it is unlikely to be a problem for most people.
2. Do we add the ability to kill LabVIEW if it is running?

In the line below we don't add the other version parameters when using an lv-exe option.

Later the port registration tries to use these for an ID. We need to enter placeholders at least here

https://github.com/JamesMc86/LabVIEW-CLI/blob/0a0c45c265326829c9423f1da99a9391f9027438/C%20Sharp%20Source/LabVIEW%20CLI/Program.cs#L218

Running under jenkins our Open Detection seems to be failing - perhaps things are running at a different rate? See log below.

Current Version: 2017, 32bit
Detected LabVIEW versions:
2017, 32bit(C:\Program Files (x86)\National Instruments\LabVIEW 2017\)
2017, 64bit(C:\Program Files\National Instruments\LabVIEW 2017\)
Launching Program:
C:\Program Files\National Instruments\LabVIEW 2017\LabVIEW.exe "C:\Users\Public\Documents\National Instruments\LV-CLI Common Steps\steps\run-vi-tester.vi" -- -p:54485
LabVIEW/App started, process ID is 260
Process Name LabVIEW
Waiting for connection on port 54485
Process Exited after one second: False
LabVIEW/App exiting...
LabVIEW exited with code 0
LabVIEW terminated unexpectedly!
script returned exit code 1

A file extension check added in 4fdfaa9 prevents the tool launching labview built executables. This needs to be fixed and verified.

If the port we try and use fails, we should attempt additional port numbers to a limited range.

I'm guessing that there's a 1024 character limit somewhere that's causing a crash. OUTP + 1020 = 1024.

If LabVIEW was terminated, and on the next start it asks user to recover files, and we try to launch LabVIEW by CLI command, it gives the following error:
"Error receiving header: Header bytes missing, received 0 of 4 bytes
Read Error"
And it is difficult to realize what is the problem, b/c if CLI runs from Jenkins service, then LabVIEW windows are not visible (at least, I have it somehow like this, I guess it's because of user context).

But, anyway, is it possible to force LabVIEW on start from CLI to skip recover option?

Thanks a lot in advance,
Sincerely, kosist90.

First I was glad to find this small program ..... but, I cannot start it.

First of all, I agree, a simple solution to communicate in a straight way with LV would be great to have and is simply missing (explicitly for my purpose - I want to run a set of programs via a command interface and extend it later to a batch job which I can reconfigurate during the running).

So, I installed your program and tried to test your Demo:

LabView-CLI "CLI Demo.vi" -- 3
(just to see if "3" is correctly accepted)
and I get the following response: LabVIEW terminated unexpectedly

My System: Windows 7, 64 Bit & LabView 2012

Do I have to tell that I use Labview 2012 and not LV 2014 (see comment on your instructions:
--lv-exe: LabVIEW Executable to use. Defaults to LV 2014 32 bit default path at the minute.) ?
But I also tried LabView-CLI --lv-ver 2012 "CLI Demo.vi" -- 3 with the same result (btw - it would be instructive to write on your page how to change the version)

Stupid question - can I also apply your program not to the vi but to the exe generated by the build function ?

If we can avoid sending the port number over the command line to LabVIEW we can remove the limitation of having to launch LabVIEW and we should be able to run with LabVIEW already open.

We would need someway of registering a port though and it needs to be dynamic because as soon as we support this users will want to run multiple instances at the same time. I don't know if such a thing exists.

We would also have to be prepared that a lot more could go wrong on the LabVIEW side. What if we launch a VI that is already open? How do we feed this back to the user?

I think this maybe a no-go but it is worth exploring options.

See the log below. Notice the change to a new PID but we still try and kill the old one.

`LabVIEW/App started, process ID is 15764

Waiting for connection on port 51089

Client Connected

Connection to LabVIEW timed out!

LabVIEW process exited. Checking for process switch

LabVIEW still found with PID 14908

killing LabVIEW process (15764)`

Hi @JamesMc86 if I wanted to contribute to this project it will be useful to know, how you setup your development environment. I tried working from a arbitrary location, git clone and then tried opening the DCAF build-system common steps. Since it relies on a lot of JKI packages, it is easier to download from VIPM. If I then try to clone in "\Wiresmith Technology\LabVIEW CLI" you can see the name of the folder is different, LabVIEW-CLI vs LabVIEW CLI and the structure inside is not a match with the repo. I'm able to have both, the git source and the installed version, but need to be really careful when linking the VIs.

I'm not suggesting it needs to change be but I'm curious how you configure you development environment. I can make changes to the installed location and the do a compare and manually pull them to the repo but it sounds strange.

It will also be useful to know LabVIEW version so I don't recompile it too far :)

I think we include the MSI in the package install and run as post action.

Tips from Matt were to run in silent mode if supported - They have done something like this with Putty in DCAF so track that down for inspiration

Returning an exit code higher than 4927 will return an exit code value of 4927.

Also returning a negative exit code will return an exit code value of 1061109567.

Could it be a problem with the byte code conversion?

    public int extractExitCode(string msgData)
    {
        Byte[] codeBytes = new Byte[4];

        codeBytes = Encoding.ASCII.GetBytes(msgData.ToCharArray(0, 4), 0, 4);
        Array.Reverse(codeBytes);

        return BitConverter.ToInt32(codeBytes, 0);

If I try to use a relative path to an exe e.g. ./exes/echo.exe then we get an exceptions. The process API requires an absolute path. (or a start path?)

After the library sends an exit with error code, the CLI receives this (displays on console) but the application doesn't actually quit and return to command prompt.

Hi James,

Have you seen this VIPM Crash?

Any chance you have instructions on how to install manually?

Need to see why this is happening or if it is related to the build script.

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.

I've seen a circumstance where:

• LabVIEW Is Open
• We run the VI
• The client Connects
• The tracking thread exits because of the process handover failing (See #55)
• the system hangs (and LabVIEW has high CPU).

It isn't 100% clear if this is due to CLI or not but should be investigated. What happens if the client connects but then the thread dies?

Example:

labview-cli TARGETAPP.EXE -- arg1=0

In this example the target app is not recognized as an executable because the .exe is in uppercase.

I am calling a compiled Labview executable with the Labview-CLI tool. It works perfectly on a machine that has both the Labview Runtime and any version of Labview development enviroment. 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 check should be skipped when the launch program is an exe.

There is now a lot of confusion with NI LabVIEW-CLI. I think perhaps we should consider a new name. There were a few ideas on twitter - please comment below with other ideas.

They were:

"Command Line Interface for LabVIEW" or "CIFL"
"LabVIEW Automation Interface"

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"

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

Rather than specifying a path to LabVIEW, it would be great if you could specify a version and bitness and it launches that instead.

Could just guess the default paths but really we would need to query install locations from the registry keys or similar.

This will make it easier to run multiple VIs in one instance.

In nearly all of my steps that use the CLI, I add in basically the same error handler at the end.

Something like this:

Might be nice to just include that snippet in the exit with code VI such that by default any incoming errors are reported to the console and report a failure to Jenkins.

For some reason we have a guard that we don't read the TCP buffer if length is only TYPE_BYTES. This means the TYPE is left in the buffer and corrupts the next read.

This will result in the following exception:

Unhandled Exception: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: size
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at LabVIEW_CLI.lvComms.readMessage()
   at LabVIEW_CLI.Program.Main(String[] args)

Its common with the command line to have a series of optional arguments. e.g. -o results.xml -ver 2014.

The tool could include support for parsing these into a variant dictionary.

If you have an invalid LabVIEW path or a path to an version of LabVIEW that isn't installed an exception occurs.

This needs to be checked and handled properly.