I'm unable to load some of my VIs into TestStand from LabVIEW. I am using:
I have the appropriate patches installed for both TestStand and LabVIEW, and I still get the error.
Attached is a message that I get when I hover over the "!" to explain my error. The VI has the "Simple Error Handler.vi" as part of the build, and when I eliminate this VI from my VI, TestStand then loads correctly.
Solved! Go to Solution.
Did you try mass-compiling that particular VI ensuring that none of your VIs were marked as read-only prior to the mass-compile? Another thing you can try to do is create a source distribution of this one VI and see if you can then load the VI, that was packaged in the source distribution, in TestStand using the LabVIEW Run-Time Engine. When you build the source distribution, you should make sure that vi.lib, instr.lib, and user.lib VIs are included in the source distribution.
Hope this helps. Please let me know the outcome.
I did mass compile the whole directory, and made sure that all files were read/write.
One of the tests that I have done with my local field agent is start a brand new sequence, add an action step, and point it to the Simple Error Handler. All this while the LabVIEW Adapter is set to LabVIEW RunTime. This simple test does not load the VI into TestStand.
I will try the LabVIEW Distribution since I am having other issues with the TestStand Deployment Tool.
I am building my source distribution file by file just to see if anything breaks instead of jumping right in and trying to build the distribution with the 20 files that I eventually need. One issue that I ran into is that I had to select the option "Remove unused members of project libraries" to get this to work. Could TestStand be having similar issues?
At this point, I think that we will be able to resolve your issues quicker if we communicated directly. Would it be okay for me to get your contact information from the forum administrator?
We were able to narrow down the cause of this issue. The Simple Error Handler.vi calls subVIs that are configured with the Separate compiled code from source file option checked. Normally this would not cause any problems when attempting to load VIs in TestStand using the LabVIEW Run-Time Engine, however, it seems that the VIs in error.llb were in a bad state and were not behaving correctly with the Separate compiled code from source file option checked. Replacing error.llb, on the computer exhibiting the problem, with a copy of error.llb, from a computer that did not exhibit the problem, resolved the issue.
Hope this helps others who might run into this unexpected scenario.
I just came across this issue with my test sequence. Thanks so much for posting this thread. I could have spent a lot of time searching for it. As an FYI the VI that I was calling had the JKI state machine and one call to the general error handler in the error state. I commented out that VI call and it loaded into the RTE.
This fixed my issue as well. Thank you for posting this. I have repaired LabVIEW 2010 sp1, LabVIEW FPGA, LabVIEW RT, DAQmx, and VISA 5.0. These are not small programs to do repairs on. Even after doing all of these repairs I still had issues with just labview coming up.
Just by clicking on my lv shortcut to run the labview.exe I would get a loading screen for gws_int.vi This was before opening any projects or VI's. Labview was having many issues. Once the loading vi screen went away the standard labview 2010 startup page was present. But this page was dysfunctional. For example if you clicked tools and then options it would just totally crash LabVIEW, no error message or warning.
Many people are suggesting to mass compile to fix this, but that is not an option. If you went to tools>advance>mass compile the same loading vi screen would come up (pic A), but then the mass compile program would have a broken arrow (pic b) I included a image to show people this.
The error list will always pop up, but there are no errors.
I called NI tech support and they suggested that I repair all of my programs starting with the largest programs first. During the repairs I found this forum. I have over 30 different NI modules installed on this machine, I would have been at this for the next two days.
Thank you very much for this.
A good question is why didn't the repairs of these large programs find this, and would any repair of any module have fixed this?
Sorry to drag up and old(ish) solved thread but I'm having a very similar problem that the solution here doesn't solve. I'm currently developing a sequence that runs a suite of Labview-based tests. I'm using TestStand 2010 (4.5) and Labview 2010 (SP1).
When I run the sequence in development mode it will run fine but when I switch over to use the run-time engine just one of the tests fail and I am presented with the following error message:
The full text of this error is:
"Failed to load VI 'C:\IntuneTest\rci_TXP_CAL2_Config\TXP_CAL2_Config\Supported_Products\IN80005104_Rev02_RelB\TSLayer_TXP_CAL.llb\TSLayer_Save_and_Verify_TXP_EEPROM.vi'
in the LabVIEW Run-Time Engine version '10.0.1'.
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located.
Select File>>Open to open the VI and then verify that you are able to run it.
VI Path: C:\IntuneTest\rci_TXP_CAL2_Config\TXP_CAL2_Config\Supported_Products\IN80005104_Rev02_RelB\TSLayer_TXP_CAL.llb\TSLayer_Save_and_Verify_TXP_EEPROM.vi"
This seems to be a standard run-time error from what I've read.
The steps I have taken so far are as follows:
Mass-compiled all relevant libraries.
Replaced the error.llb file
Checked all associated file paths.
None of the above steps have helped. The path highlighted above is a valid path as other module calls in the sequence are calling from the exact same linked library and run flawlessly every time using the run-time engine. Any help would be appreciated.