NI LabVIEW CLI won't start LabVIEW VI Server fast enough

[Bas.v.E]

So our setup is as follows:

We have a Jenkins server with BlueOcean and a windows 7 slave machine with Labview 2017 and the Labview CLI tool installed. The Jenkins server connects through SSH with the slave. So after a checkout of my code I run a build.bat with this code:

SET cur_dir=%cd%
echo %cur_dir%
LabVIEWCLI -LogToConsole true -OperationName ExecuteBuildSpec -ProjectPath "%cur_dir%\CITestProject.lvproj" -BuildSpecName "Main Application"

The problem I'm running into is that the Labview CLI tool won't start labview fast enough, so after a time of <unspecified> seconds. I get this error code:

Error code : -350000

Error message : LabVIEW CLI: (Hex 0xFFFAA8D0) The CLI for LabVIEW failed to establish a connection with LabVIEW. Ensure LabVIEW is running with VI server enabled on the correct port number. To enable VI server in LabVIEW, select "Tools>>Options>>VI Server" and enable the "TCP/IP" checkbox. If the port number under "TCP/IP" is not 3363, you must specify the port number using the "-PortNumber" argument. 

An error occurred while running the LabVIEW CLI.

After testing some thing I noticed my build works when Labview is already running before starting the build.bat.

The other thing I found was, the build.bat starts LabviewCLI, which starts labview in the background, but because of the timeout of the labviewCLI it shuts labview down again.

So without hacking my way through and starting labview before executing LabviewCLI, is there a way to increase the timeout time or something like that?

[rdecarre11]

It looks like you are using NI's LabVIEW CLI, is that right?

I use Wiresmith and I have had great luck with it. Maybe give that a shot?

If not, I only have a couple comments that helped me.

• Are you using a windows machine that is running a UI thread while all this is happening? I have noticed dramatic gains in load-times when I run-as System and don't log in to Windows. (You mentioned SSH so that may already be the case)
• If you're using a Jenkinsfile, you can wrap script in a timestamps() function to log how long between writes to the console. It can help keep track of the length of all the various steps:
  • https://jenkins.io/doc/book/pipeline/syntax/#options (scroll down a bit)
• Are you using a license server? If so, probably create a disconnected license so LV doesn't wait for the server.
• Configure LV to start up a little faster by changing the loading options http://zone.ni.com/reference/en-XX/help/371361L-01/lvdialog/function_browser_opt_db/ I use "Load palettes when needed"

[EricR]

All of the recommended things to try from @rdecarre11 seem like good suggestions to me.

LabVIEW does take some time to launch on a cold start.  The Wiresmith and NI versions of the LabVIEW CLI are implemented differently so they could require different initialization times for LabVIEW to be responsive.

How much time are you finding that it takes before the LabVIEW CLI does respond?  Especially with the startup changes suggested by "rdecarre11" it seems like it should only be a few seconds.

There is no directly way to change the timeout of the LabVIEW CLI.

[adambro]

Whilst helpful, these suggestions really sound like ways of dealing with something that doesn't work. You should be able to use the LabVIEW CLI "out of the box" without fiddling around trying to optimise LabVIEW launch times, I would suggest.

I'm seeing this same issue on my Jenkins build server and whilst it isn't the highest performance set-up, it does exceed the minimum system requirements.

I think LabVIEW CLI really should be able to cope with this better but at the very least there should be the option to specify a timeout period where the default is too short.

[Bas.v.E]

Whilst helpful, these suggestions really sound like ways of dealing with something 
that doesn't work. You should be able to use the LabVIEW CLI "out of the box" without 
fiddling around trying to optimise LabVIEW launch times, I would suggest.

This is exactly my point. I don't want to create workarounds, which I have to document because other people need to know how I did it for that project. 

How much time are you finding that it takes before the LabVIEW CLI does respond?  
Especially with the startup changes suggested by "rdecarre11" it seems like it 
should only be a few seconds.

It takes like 58 seconds or so to start labview before I can use it with the CLI tool. And that is mainly because it's loading all the plugins we use for the project. But this should not matter if NI developed the tool to wait for LabVIEW.

I'm also hoping NI will see this post and do some fixing for the CLI tool. I will even volunteer to test functionality for them if they want to.

[rdecarre11]

Yeah I certainly agree that workarounds are not ideal, and the fact that we have to deal with this subpar tool is also not ideal.

@ni-people: can we get a build of the CLI in which we can configure the start-up timeout?

[rdecarre11 · Accepted solution]

So I found a couple things in the .ini you can try:

[LabVIEWCLI]
DefaultPortNumber = 3363
AppendToLogFile = FALSE
OpenAppReferenceTimeout = 3000
AppExitTimeout = 10000
DefaultLabVIEWPath = ""
OpenAppReferenceRetryCount = 3

You can try to change theOpenAppReferenceTimeout or the retries. Looks like default is about 9 seconds.

[EricR · Accepted solution]

There are a couple of INI tokens we put into LabVIEW CLI for exactly this case. They are :

• OpenAppReferenceTimeoutInSecond - specifies the amount of time the first attempt to open a VI server connection to LabVIEW should wait before timing out.
• AfterLaunchOpenAppReferenceTimeoutInSecond - how long the CLI should try opening a VI server connection *after launching LabVIEW* before it times out.

These tokens are still in the nature of "workaround".  I'm pulling some of the development team into this discussion for thoughts on making the CLI so that it doesn't start passing along parameters until LabVIEW has launched.  That said, there could be things on the system that actually prevent LabVIEW from loading correctly and in those cases, you do want to have a timeout so that the app isn't hung waiting for something that will never complete.

[Bas.v.E]

For now the INI file solution does the trick, I would love to see the improvements in the future.

maybe not the best topic to address this but I can't seem to find an "report an issue with this page" button on this page, but I've found a mistake on the operations webpage that took me to long to figure out.

on the VIAnalyzer section there is a piece of example code where this: 

-ReportSaveType "html"

should be this:

-ReportSaveType "HTML"

[Bas.v.E]

So any update on this? I saw that the operations page still isn't updated with the correct example codes.

and I was wondering if there is a release date for the SP1 of the CLI?