VI load error

[BowenM]

So, I have VI loads fine with LabVIEW adapter configured to Development.  The moment I configure the adapter to Run-Time, TestStand returns an error saying that it can't load the VI.  I have no idea what could be causing this... troubleshooting ideas?

Unfortunately, I can't post the VI.  It is an API call into one of my main classes that calls other classes that... etc.

Here is my configuration in "Development"

The VI loaded just fine

Configuration for Run-Time

And the resulting error message

[kosist90]

I guess that error description tells everything - most probably, you have missing dependencies. If you'll take normal (not deployed VI), which uses some dependencies VIs, and try to run it via Run-Time Engine, it'll drop you an error b/c dependencies are missing.

So in your case it's better to create deployment image of the sequence and code modules, and just then run it via Run-Time Engine...

Hopefully, it'll help,

Sincerely, kosist90

[WireWeaver]

The last paragraph of this help document has one explanation:

---

---

Normally, the LabVIEW RTE can execute top-level VIs only when you save the VI with the entire VI hierarchy or when the LabVIEW RTE can locate the subVIs using the LabVIEW search directories. By default, the LabVIEW RTE does not search for required subVIs within the LabVIEW development system, such as files in vi.lib. However, when TestStand loads a LabVIEW RTE on a computer where you also installed the LabVIEW development system, TestStand automatically adds directories from the development system to the search paths for the LabVIEW RTE, but only for directories where the version of the development system matches the version of the LabVIEW RTE. Therefore, when TestStand executes a top-level VI saved without a hierarchy, the LabVIEW RTE searches the directory of the top-level VI and then searches the directories TestStand added to find subVIs. When the LabVIEW RTE finds a subVI saved in a different version of LabVIEW first, the LabVIEW RTE cannot load the subVI and does not load the top-level VI.

Unlike the RTE, the LV development environment can recompile VIs if it needs to. Best troubleshooting steps:

1. Mass compile all of your VIs in a single version of LabVIEW.
2. If you still have the problem, use a diagram disable structure to incrementally disable subVIs until you find the culprit and go from there.

There are a few other reasons for this error, like having two different VIs with the same name in memory, but above is the most common.

Hope this helps!

Trent

[BowenM]

kosist90:

It is absolutely not missing dependencies OR broken vi / subvi...  If it was then the VI would not load in development either.

WireWeaver:

1.  I've already done a mass recompile.

2.  😞  Just these classes contain ~400 vis.  That's a lot of disabling one at a time and recompiling to test...

With regards to "wrong LV version of subvi", I have two concerns here.

1. It worked flawlessly last build.  All new code generated between last build and this build was done in LV2016 - I've added no 3rd party packages or anything in between.  

2. If I develop the sequence file with the adapter set to Development and save the sequence, then change the adapter to Run-Time and execute the sequence file programmatically from LabVIEW (with the vi that supposedly can't load) it runs correctly.  I assume if the subvi actually couldn't load it would throw an error when executing the sequence. This doesn't happen.

Note: Everything LabVIEW I'm talking about here is compiled code as part of a larger application. The API call that won't load, the program that executes my "broken" sequence file... all compiled code running from a Run-Time environment.

[WireWeaver]

---

2. If I develop the sequence file with the adapter set to Development and save the sequence, then change the adapter to Run-Time and execute the sequence file programmatically from LabVIEW (with the vi that supposedly can't load) it runs correctly.

---

That's interesting - if you ignore the error and run it from the sequence editor, does it work? (might have to click through analyzer pop-ups).

This brings LV Application Instances to mind.  The error you're posting about is mentioned towards the end of this document, but under opposite circumstances from what you've described above. Regardless, it's worth taking the time to understand the content of this white paper.

[BowenM]

---

WireWeaver wrote:

That's interesting - if you ignore the error and run it from the sequence editor, does it work? (might have to click through analyzer pop-ups).

---

No.  The sequence editor won't run the file.

I also wanted to verify that it wasn't some odd behavior machine specific so I tested it on multiple machines and it was consistent - one of which was a Windows PXIe pc with the default NI image. I also verified that if I created a new sequence file from scratch (previously I'd been using existing files) it would act the same.

[WireWeaver]

In that case, I would resort back to this:

WireWeaver wrote:

If you still have the problem, use a diagram disable structure to incrementally disable subVIs until you find the culprit and go from there.

---

---

Since the OI is able to load the dependencies correctly, the place to start would be any subVIs shared between the code module and the OI. Once you figure out the conditions causing it, post a small reproducing case here - or open up a ticket with NI support to see if this is a bug.

Improved error reporting for this is something we're looking into, so i'd be curious to know the cause.

[kosist90]

---

@BowenM wrote:

kosist90:

It is absolutely not missing dependencies OR broken vi / subvi...  If it was then the VI would not load in development either.

 Don't fully agree with it. Recently I've played with this topic - changed adapter type from dev. environment to run-time engine for my sequence. And it didn't work. Although, in development environment all code modules loaded fine.

But after mass compile, it started to work.

---

2. If I develop the sequence file with the adapter set to Development and save the sequence, then change the adapter to Run-Time and execute the sequence file programmatically from LabVIEW (with the vi that supposedly can't load) it runs correctly.  I assume if the subvi actually couldn't load it would throw an error when executing the sequence. This doesn't happen.

Note: Everything LabVIEW I'm talking about here is compiled code as part of a larger application. The API call that won't load, the program that executes my "broken" sequence file... all compiled code running from a Run-Time environment.dfsfsdf

This can be again issue with VIs conflict in memory. While you run it via LabVIEW application, you already have some VIs loaded to memory. Thus, if those VIs are the one, what are missing for Run-Time engine while running from TestStand, then code modules have all needed Vis already loaded.

And from TS it can not preload them, and this causes issue with code modules loading.

So I beleive, that this is all about missing dependencies for code modules, while using Run-Time engine. @WireWeaver gave a good explanation from TS help - there are differences, how TS loads code modules with dev. environment; and with RTE environment.

Do you open your sequence file, when you have also loaded code of that larger application, what you've mentioned? How do you make sure, that code modules in dev. environment are really loaded just within TestStand, and not LabVIEW? I had situations, when I had opened LV project, and sequence which used VIs with the same names, and afterwards TS swapped original code modules steps, with another one, from the different project.

I'm curious how it will be solved, but still I beleive that this is everything about compilation, and dependencies issue for RTE.

[NickNZ]

Something to check if you haven't solved it yet - I had a problem building a deployment due to a VI Library referencing a missing VI (That my sequence didn't use - but it used others in the library)... so ran fine in development, but I couldn't build it. Perhaps try to see if you can create a deployment and if it throws any interesting errors. (Note error message in my case was just that the build failed so it wasn't helpful, but may give you some clues).

[BowenM]

Thank you all for your responses.  After more troubleshooting than I care to admit and a call to NI I was able to resolve the problem.

The short version:  You were all sort of right - missing dependencies and application instances.  I had exposed part of my application to TestStand as an API by sending all of my subvis to the "Support Directory".  A new typedef cluster that was part of my main API class had been added at a top level and wasn't added to the support directory.  When the TestStand sequence editor looked for the path it searched exactly as LabVIEW would - <application path>\application.exe\...

Needless to say it didn't find any file there and failed to load.  Yet in the application of course it ran fine.