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?