In the middle of running some TestStand sequences, calling LabVIEW code, I lost connection to the VI Server, and started getting the attached error:
I have searched through previous solutions on this board, including:
Each of which had a couple of KB articles referenced, but those steps do not solve the issue. All the VI Server items are enabled on LabVIEW (and were working up until a couple hours ago). I restarted everything, but I keep getting the same error.
this is TestStand 2012 SP1 f1 (22.214.171.124), and I installed the recent patch, as that was alluded to in several other posts.
It is communicating with LabVIEW 12.0.1
What other issues might be causing this V Server error?
i recommend you to dig into general information first.
As i understand, there are already steps executed which include LV modules. Correct?
If so, they obviously dont generate any runtime error. So what makes this step specific?
Also, if it is reproducible (on several machines?), please provide a simple example.
In this case, it was the exact same step (with the same VI) that went from working to non-working.
The difference that was made was that I started pointing to the project first, and then the VI, rather than directly to the VI. When using the project, the VI Server settings on 'My Computer' target were actually overriding the VI Server settings in Tools>Options.
So, the solution is to make sure the Project> My Computer>Properties> VI Server settings (machine Access, exported VIs) have the * in them, in addition to the general LabVIEW settings.
I'm working through a problem right now that might cause what you're seeing. That's how I came to your thread. Unfortunately, no solution yet, but might be something for you to try that could help characterize the issue.
So, I need to control an exe remotely using VI server. I set the port 3364. Works fine. The program calls a .net assembly that interfaces with Teststand. For some reason, as soon as I call that assembly the VI Server port changes from 3363 to a random value, somewhere around 64832. At first I used "netstat -a" from command prompt to verify the port. When it wasn't working, I could see that port had disappeared from the listening list. On the exe I put an indicator on the front panel, and can see the change when I use remote debug and step through the code and pass the .net/Teststand subVI. I've also got a property node that enables VI Server logging and I see that change in the log. I've made other calls to this .net assembly that do not cause the change, so I'm thinking Teststand is doing it. Just need to figure out how to prove it.
Like I said, I'm still not sure what's happening with my code, but you might check to see if that port is still active on your computer using netstat -a.
Hope that helps!