LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Built exe not connecting with vi server, port conflict

This is not a request for help, I was lucky enough a very smart teammate saw the solution. 

 

I was unable to find info on fixing this issue so I wanted to post it here to help others.  Also I wanted community feedback on my proposed change to some default behavior in LabVIEW. 

 

The setup is I am building a CI helper tool so the CI runner (gitlab runner in this case) calls my exe via g-cli (thanks James) and the my application establishes a vi server connection to some version of LabVIEW (depending on the CLI call).  See how the connection with the vi server is established below. 

 

connect.PNG

 

So I was getting an error where when LabVIEW was not already running I would get a buffer overflow when it tries to establish the vi server connection after launching the appropriate version of LabVIEW. 

 
 

err1.PNG

 

But when LabVIEW was already running when you call the tool, no problem, connects to the vi sever and will do it's job no issues. 

 

Now what the problem ended up being was that the exe was assigned to use the same port as the LabVIEW version it was calling so if it was called first it locks that port and thus you get the overflow.  It was a stupid easy fix in just changing the server.tcp.port in the exe's ini file or alternately setting the server.tcp.enabled=False.

 

My change to the default behavior would be to make sure that the default exe ini is assigned a port number that is in a different default block of LabVIEW. Or that the vi server is off by default in an exe, and if you need to use it you have to turn it on and beware the fallout. 

 

 

 

 

 

 

 

0 Kudos
Message 1 of 1
(1,532 Views)