Continuous Integration

cancel
Showing results for 
Search instead for 
Did you mean: 

Trouble using LabVIEWCLI

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

0 Kudos
Message 11 of 19
(3,741 Views)

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/releasesships 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.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
Message 12 of 19
(3,729 Views)

@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

0 Kudos
Message 13 of 19
(3,724 Views)

@James_McN wrote:

why not try G CLI


I held myself back from posting this 🙂

 

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




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (Developer Experience that makes you smile )


0 Kudos
Message 14 of 19
(3,717 Views)

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

0 Kudos
Message 15 of 19
(3,660 Views)

removed double post

 

 

0 Kudos
Message 16 of 19
(3,653 Views)

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

Message 17 of 19
(3,478 Views)

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

0 Kudos
Message 18 of 19
(1,573 Views)

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

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 19 of 19
(1,558 Views)