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

[EricR]

Bas.v.E,

What "operations" page are you looking at and what example codes are you asking to have updated?

I'm checking on the CLI.  If the component was updated with the LabVIEW 2018 SP1 release, NI will post a new version to NI.com in early January. 

[Bas.v.E]

This operation help page:

http://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/cli_predefined_operations/ 

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

-ReportSaveType "html"

should be this:

-ReportSaveType "HTML"

[Jon_Kokott]

Where is the ini you speak of?

<LV_Version_Path>\labview.ini?

no keys are currently there for me in any labview version.

[Bas.v.E]

The Union file is located in 

C:/program files(86)/national instruments/shared/labviewcli/

[cknowlto]

This is still a serious problem.  I can not find any combination of timeouts that will allow my Jenkins labview builds to succeed.

I am using labview 2019 SP1 on Windows Server 2016

I have tried timeouts from 5 - 60 seconds and I almost always get Error Code 350000

Any suggestions from the crowd?

[ryan_sheppard]

https://github.com/JamesMc86/G-CLI

Use this instead. All my similar issues were solved.

[cknowlto]

So someone wrote a wrapper to fix this issue instead of NI actually fixing the problem? 

So why do we pay these guys all this money for support then?

[ryan_sheppard]

I mean, it's an open source project by an individual who has contributed to the LV community for years. I like that it's an open source solution, we don't need to rely on NI for everything.

NI most likely has many other internal projects they are working on. Spending time on a tool that I would guess less than 1% of the community uses doesn't make business sense.

G-CLI gets the job done.

[Oli_Wachno]

I have talked to some guys from NI some time ago....  the statement was: take James' tool, it seems to work better.

[AgentAstronaut]

I have used LabVIEW CLI with azdo and Jenkins and have run into this issue in both cases. Sometimes the solutions in the forum do not work, or the timeout is simply too long to deal with. My solution has been to call LabVIEW.exe prior to calling the CLI. For instance, in AzDo I store the version of LabVIEW I am using for my build as a variable $(lvVersion) then use it to call LabVIEW at the location of the LabVIEW executable.

steps:
- task: PowerShell@2
  displayName: "Open LabVIEW"
  inputs:
    targetType: 'inline'
    script: Start-process -FilePath "C:\Program Files\National Instruments\LabVIEW $(lvVersion)\LabVIEW.exe"

   Then I call the LabVIEW build spec through the CLI:

  - task: PowerShell@2
    displayName: "Execute LabVIEW Build Spec"
    inputs:
      targetType: 'inline'
      script: LabVIEWPath "C:\Program Files\National Instruments\LabVIEW $(lvVersion)\LabVIEW.exe"

Your Mileage May Vary