I am receiving "LabVIEW: VI Server access denied." from TestStand 2010. This is using LabVIEW 2011 on Windows 7 but only started happening after I had transitioned to using the Run-Time engine for a while.
I ran into this when trying to convert back to the development system for the configuration adapter due to needing to update some 130 steps worth of prototypes which takes a long time to do while running the run-time engine version.
I have some questions to better identify the issue:
1) Can you run the VI/LabVIEW executable on its own?
2) What is the LabVIEW module doing?
3) Which program are you running on the run time engine, LabVIEW or TestStand?
4) You are trying to convert the machine back to a development license from a deployment license for TestStand, or LabVIEW?
5) What LabVIEW toolkits/module are you using?
Thanks for the response Alexandra,
1) The project and VI both run perfectly fine on the same system from the development environment.
2) The LabVIEW module is a conglomeration of various instrument calls to accumulate some amount of data which is returned to Test Stand for Pass/Fail status and logging.
3) I can run the sequence with TestStand LabVIEW Adapter configured for the RunTime, setting the LabVIEW adapter to Development System is when the VI Server access denied appears.
4) System has always been a development system, I just switched the adapter over to RunTime engine to speed up operation of the test, now I am in integration with hardware and made a few changes that need to be updated in the sequence. I brute forced the update with runtime, but it took several hours to do for a 140+ step test.
5) The only additional toolkit for LabVIEW is the FPGA one I believe, everything else is standard LabVIEW Professional.
Does this article help? There are a number of different issues that could cause this problem, but this one is the closest I've gotten to your specific situation.
Also, in LabVIEW, go to Tools>Options...>VI Server, then scroll down to "Exported VIs", and make sure an asterisk is listed there to allow access to all calling VIs.
I have looked at the LabVIEW VI server settings many times in hope that I missed something, but alas, I am familiar with LabVIEW VI server as I have used it a good deal, and the settings are all proper.
My only remaining thought is that it has something to do with blocked Active X on Windows 7, but I am not sure how to test/verify that. Or its some other minor setting in project or sequence, when I get time I will see if I can get another sequence to work with random project/VIs using the development engine.
Is there any way to set TestStand to use a TCP/IP VI Server?
What version of LabVIEW were these modules written in? Have you installed a newer version since development?
Have you ever been able to switch between the run-time engine and the development system successfully, or is this the first attempt?
For the TCP/IP server, you would need to create a custom step type. Check out this article about TCP/IP communication in TestStand.
The LabVIEW is all 2011 SP1, there has been no additional updates since the original install. Initially, several months ago, the project was able to go back and forth between the development and runtime while I figured out how to make runtime work.
The article appears to be just basic TCP/IP, so it won't quite work to debug the VI server. Though I suppose it woud be possible to see if I can duplicate the VI server error between two different LabVIEW instances and/or see if switching to a TCP/IP version to see if it resolves it, which would indicate it being an issue with active X being blocked.
Can you think of anything that has changed about this computer since the that period several months ago when you were switching between the run time engine and the development system? Major software installs, Windows updates, antivirus programs, etc?
Do you have admin privileges on the computer? The VI Server requires admin privileges. If you right click an executable, you can select the option to always run as admin.
Can you post a screenshot of the error you receive?