topic Re: Trouble using LabVIEWCLI in Continuous Integration

Trouble using LabVIEWCLI

Oli_Wachno — Thu, 13 Jun 2019 13:20:39 GMT

Hi there,

I started playing a bit with LabVIEW CLI 1.1 but have failed miserably so far

Starting small, I thought just to have a short pipecleaner masscompiling a directory

LabVIEWCLI -Verbosity Diagnostic -LabVIEWPath "C:\Program Files (x86)\National Instruments\LabVIEW 2017\LabVIEW.exe" -PortNumber 3364 -OperationName MassCompile -DirectoryToCompile "C:\Test"

LabVIEW launches, but CLI returns with an error. The diagnostic file holds the following information

Using LabVIEW: "C:\Program Files (x86)\National Instruments\LabVIEW 2017\LabVIEW.exe"
LabVIEW launched successfully.
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.

VI Server seems configured correctly

So I thought, I'd try changing the VI Server Port to 3364, just to try

Same thing happens:

LabVIEW launches, an error is reported on the command line, LabVIEW stays open.

To check if VI Server is working correctly, I have used VI Package Manager to verify the connection. This works fine.

Any ideas?

Cheers

Oli

Re: Trouble using LabVIEWCLI

StefanLemmens — Thu, 13 Jun 2019 13:40:57 GMT

Make sure the Machine Access List allows access for 127.0.0.1, this is necessary to allow the communication between the LabVIEW-CLI and VI Server.

Best Regards,

Stefan Lemmens

Intersoft Electronics

Re: Trouble using LabVIEWCLI

Oli_Wachno — Thu, 13 Jun 2019 13:51:01 GMT

@StefanLemmens wrote:

Make sure the Machine Access List allows access for 127.0.0.1, this is necessary to allow the communication between the LabVIEW-CLI and VI Server.

Best Regards,

Stefan Lemmens

Intersoft Electronics

Thanks for the tip. Added 127.0.0.1 explicitely yet it does not help in this case.

Re: Trouble using LabVIEWCLI

StefanLemmens — Thu, 13 Jun 2019 13:53:33 GMT

Another problem might be that the LabVIEW CLI won't start VI Server fast enough.

You can find more info here.

I got it to work with these settings:

AppExitTimeout = 10000
OpenAppReferenceTimeoutInSecond = 30.000000
AfterLaunchOpenAppReferenceTimeoutInSecond = 90.000000

Due to this we switched from using the LabVIEW-CLI to G-CLI

Best Regards,

Stefan Lemmens

Intersoft Electronics

Re: Trouble using LabVIEWCLI

Oli_Wachno — Thu, 13 Jun 2019 14:02:17 GMT

Ok.... so I raised the time-outs as described. Error remains.

I shall try on a different computer outside the corporate enviroment... maybe there is some strange group policy which keeps this from working. Wouldn't be for the first time....

Thanks for the input!

Oli

Re: Trouble using LabVIEWCLI

StefanLemmens — Thu, 13 Jun 2019 14:29:53 GMT

Just noticed in your screenshot that the portnumber (3363) doesn't match the one in your command line (3364).

Best Regards,

Stefan Lemmens

Intersoft Electronics

Re: Trouble using LabVIEWCLI

Oli_Wachno — Fri, 14 Jun 2019 06:01:48 GMT

@StefanLemmens wrote:

Just noticed in your screenshot that the portnumber (3363) doesn't match the one in your command line (3364).

Best Regards,

Stefan Lemmens

Intersoft Electronics

Hi Stefan,

you're right. The code and the screen shot don't match: took the screen shot while experimenting.

BTW: tried at home last night on a VM with LV2018: worked smoothly. Next step will be to set up a VM with LV2017 and check again.

Cheers

Oli

Re: Trouble using LabVIEWCLI

StefanLemmens — Fri, 14 Jun 2019 08:01:07 GMT

Hi Oli,

how smooth is "smoothly"?

I still have a very long delay (more then 30sec) between running the command and LabVIEW actually doing something.

Best Regards,

Stefan Lemmens

Intersoft Electronics

Re: Trouble using LabVIEWCLI

Oli_Wachno — Fri, 14 Jun 2019 08:13:22 GMT

Hi Stefan,

smooth as in it is working on that particular VM using the standard parameters of the CLI INI file.

But: this is a LabVIEW only installation. No toolkits like RT or FPGA installed.

But speaking of slow spinup.... I remember having had troubles with an old version of the SVN Toolkit when opening large projects. Don't know if this is still the case.

Oli

Re: Trouble using LabVIEWCLI

Sam_Sharp — Wed, 17 Jul 2019 11:34:30 GMT

Did you download the CLI from the web? Do you need to 'unblock' it in the exe properties?

Of course, it may be that you need to unblock the executable on your firewall...your IT policy might only allow signed/whitelisted executables to have network access on certain ports.

Re: Trouble using LabVIEWCLI

Oli_Wachno — Wed, 17 Jul 2019 11:48:43 GMT

Hi Sam,

I have tested with LabVIEWCLI downloaded as an separate package for LV2017 as well as a pristine LV2018 installation. Both show the same result.

What really makes me wonder is that other tools like the VIPM are using VI Server without any issues. So there seems to be a difference in the usage of VIServer which triggers the Firewall. I want to understand what in order to discuss with my IT guys.

Regarding execution privileges: LabVIEWCLI does launch from the command line window (also tried to run the CMD window as admin), LabVIEW even spins up, yet something refuses the connection.

Cheers

Oli

Re: Trouble using LabVIEWCLI

James_McN — Thu, 18 Jul 2019 06:20:15 GMT

Hi Oli,

Sounds like a pain! Of course, I have to mention, why not try G CLI and see if it is any different? The latest version (2.1.0 - should be on the tools network now but if not https://github.com/JamesMc86/G-CLI/releases) ships with an echo tester so you should be able to install the package and then run:

g-cli -v --lv-ver 2017 echo -- test1

This will launch 2017 and should just echo back test1.

At least you might get more clues about why it is being blocked. G CLI reverses the connection. G CLI opens a server on a random port which LabVIEW connects to (the port number is passed through the NI service locator). If your IT is somehow blocking unknown applications this will probably be blocked as well. If it works then either LabVIEW is specifically being blocked or it is some other issue with VI server.

Re: Trouble using LabVIEWCLI

Oli_Wachno — Thu, 18 Jul 2019 07:19:59 GMT

@James_McN wrote:

Hi Oli,

Sounds like a pain! Of course, I have to mention, why not try G CLI and see if it is any different?

Hi James,

not tried yet, but I will definitely do asap.

Cheers

Oli

Re: Trouble using LabVIEWCLI

joerg.hampel — Thu, 18 Jul 2019 13:31:59 GMT

@James_McN wrote:

why not try G CLI

I held myself back from posting this 🙂

But, of course, +1 for G-CLI.

Re: Trouble using LabVIEWCLI

Oli_Wachno — Thu, 01 Aug 2019 10:32:52 GMT

Short update (after having found some minutes to tinker)

I have persuaded my IT guys to let me configure the local firewall.

After configuring incoming connections and unblocking LabVIEW, it seemed to work excactly once.

I have tried over and over again also incrementing timeout values in the ini-File. Every ~10th attempt works... so I think it's rather not an issue with the firewall

Re: Trouble using LabVIEWCLI

Oli_Wachno — Thu, 01 Aug 2019 12:30:35 GMT

removed double post

Re: Trouble using LabVIEWCLI

leahmedwards — Mon, 08 Jun 2020 14:37:27 GMT

Just wanted to share a potential solution for people ending up on this page.

I had been having similar problems for months: symptoms being:

- I could run G-CLI and LabVIEW CLI from command line on my PC, no problem

- If triggered from Azure Devops Pipelines to that PC (self-hosted build agent), would get 'TCP failed to connect' error messages for both, and timeouts.

- Disabling the entire firewall did not help

- (The weird one) - If I opened LabVIEW then triggered the Pipeline, LabVIEW CLI would work but G CLI would not.

The solution is very simple. IT had set up my DevOps build agent to run as a service on a different Windows user account to the one I normally used. When I eventually got them to log in as that Windows user, it was the first time it had ever logged in. There were a gazillion popups about setting up various programs. When I launched LabVIEW, it had not found the volume license server so I had to add it to the correct group. There was also a popup about whether I wanted to launch LabVIEW 2018 or LabVIEW Robotics, which might have stopped it from communicating with either. After I had set all of this up, my pipelines worked fine.

Hope this helps someone.

--Leah

Re: Trouble using LabVIEWCLI

ch33rs00 — Thu, 09 Nov 2023 14:16:46 GMT

Hello guys,

I was trying to use the LabVIEWCLI via a batch file executed by Jenkins. I encountered the same error. What solved it for me was setting the working directory to the one of my LabVIEW installation (C:\Program Files\National Instruments\LabVIEW 2021).

So instead of just using

LabVIEWCLI -OperationName RunVI -VIPath "VIName"

I tried

cd C:\Program Files\National Instruments\LabVIEW 2021
LabVIEWCLI -OperationName RunVI -VIPath "VIName" .

Re: Trouble using LabVIEWCLI

Taggart — Fri, 10 Nov 2023 15:38:13 GMT

@leahmedwards wrote:
Just wanted to share a potential solution for people ending up on this page.

I had been having similar problems for months: symptoms being:
- I could run G-CLI and LabVIEW CLI from command line on my PC, no problem
- If triggered from Azure Devops Pipelines to that PC (self-hosted build agent), would get 'TCP failed to connect' error messages for both, and timeouts.
- Disabling the entire firewall did not help
- (The weird one) - If I opened LabVIEW then triggered the Pipeline, LabVIEW CLI would work but G CLI would not.

The solution is very simple. IT had set up my DevOps build agent to run as a service on a different Windows user account to the one I normally used. When I eventually got them to log in as that Windows user, it was the first time it had ever logged in. There were a gazillion popups about setting up various programs. When I launched LabVIEW, it had not found the volume license server so I had to add it to the correct group. There was also a popup about whether I wanted to launch LabVIEW 2018 or LabVIEW Robotics, which might have stopped it from communicating with either. After I had set all of this up, my pipelines worked fine.

Hope this helps someone.

--Leah

for this reason I always recommend not running as a service but as a user account.

In my case, I don't have an IT department, so I just set the VM to autologon that account and then have a bash script that runs on login that launches the runner. It works in my case. Not sure if I had an IT department if they would approve of that.

At least that way I can always RDP in as that user and then see exactly what is going on.