Trouble using LabVIEWCLI

[Oli_Wachno]

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

[James_McN]

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.

[Oli_Wachno]

---

@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

[joerg.hampel]

---

@James_McN wrote:

why not try G CLI

---

I held myself back from posting this 🙂

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

[Oli_Wachno]

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

[Oli_Wachno]

removed double post

[leahmedwards]

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

[ch33rs00]

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" .

[Taggart]

---

@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.