.vi loaded with errors on the target and was closed

[gsussman]

Some more information on this issue. I have a  large RT project (~4300 VIs , 120+ classes) that has been giving us fits on deployment.

A never ending string of ".vi loaded with errors blah blah blah" and LV crashes. Up till now it has taken between 15 and 25 minutes along with multiple object cache clears, LV restarts, and RT system reboots to obtain a successful deployment. It feels more like building FPGA code than trying to run on an RT system.

I have stumbled onto what appears to be a workable method to get the RT system to deploy. 

What we have found to work:

1) Load the RT project

2) Clear the compiled object cache

3) Attempt to deploy (for us this leads to a LV crash 100% of the time)

4) In the LV crash window, view the contents of the crash report, specifically the lvlog.txt file

Scroll to the bottom of the window and you should see something similar to the following:

---

---

<DEBUG_OUTPUT>
12/16/2016 11:24:14.129 AM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: c3b9a253-1306-43c5-ace3-886eb861081d
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x100011AB - nierInterface <unknown> + 0
0x10005E96 - nierInterface <unknown> + 0
0x10006538 - nierInterface <unknown> + 0
0x10001101 - nierInterface <unknown> + 0
0x10002109 - nierInterface <unknown> + 0
0x00692A35 - LabVIEW <unknown> + 0
0x01E43011 - LabVIEW <unknown> + 0
0x01E5647D - LabVIEW <unknown> + 0
0x755062FA - USER32 <unknown> + 0
0x75506D3A - USER32 <unknown> + 0
0x755077D3 - USER32 <unknown> + 0
0x7550789A - USER32 <unknown> + 0
0x01ED030F - LabVIEW <unknown> + 0
0x01ED0493 - LabVIEW <unknown> + 0
0x01ED0667 - LabVIEW <unknown> + 0
0x08C41AD6 - QtManager452_2015 <unknown> + 0
0x670E7251 - NIQtCore_2015 <unknown> + 0
0x00067B2A - <unknown> <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***
#** compile: "C:\<some path to your code>\<some random VI name>"
*** End Dump ***

5) Reopen your RT project and open the VI identified on the highlighted line first. Leave the VI open

6) Open your main deployment VI and attempt to deploy

In about 50% of the cases the project will deploy correctly, the other 50% will result in another crash and another error log. Repeat Step 4, until you get a successful deployment.

Using this method I can typically get a deployment to work in 1 or 2 LV restarts.

I can't guarantee this will work with your applications, but it is at least something more to try.

[MGiacomet]

Cop out!

>>"... we need code that demonstrates these bugs..."

No need for code samples, since by the variety of conditions in these many posts indicate, it has NOTHING to do with customer code. The code you need you have: it's LabVIEW!

Right now I'm in a situation that out of nowhere, it starts acting up. I then make an innocuous change in a VI, click on Save All, and sometimes during deployment I'm prompted to save unrelated VIs!!! Reason? "VI recompiled"... Why just now?! When these saves during deployment happen, then the problem goes away.

If NI cared, NI would at least start putting meaningful error descriptions. "vi loaded with errors" is useless! What errors??? Meaningful indication is the only way this will ever get resolved.

And WOW! This thread is EIGHT years old. Has NI done anything? Oh, yeah, spent time creating new fancy NextGen...

[Olivier_L]

I've got the same issue, since I'm working with LabVIEW 2017, classes, and RT targets.

Last week, I had this issue when I changed a typedef included in another typedef.

Luckily, I realized when I saved it that something didn't get as usual (I don't know how, something about the way the front panels are refreshed at save), then, thanks to this post, I realized that there were effectiveley something weird with my typedef changing, but I was unable to find somehing changed on it, and no way to update it manually.

If I remember well, I removed the Typedef I changed in the calling Typedef and included it again. probably had some popup saying to revert changes, several times, but I succeded to have it downloaded right.

Today, I just added some items into a typedef ring, not included in any other typedef.

Then, trying to run it on my RT target (where the same project was already running as an rtexe, without the ring updated), it showed issue deploying the VI (a class method containing a subVis containing the updated ring).

Also, a lot of VIs are seen as already deployed, even if I stop executing the rtexe at startup and restart the RT target hoping to deploy from a clean environment, because I expect that typedef in memory on Rt target is somewhere close to the issue.

Nothing changed.

I also tried to click "open typedef" from all instances of it on subVIs, and some of them was saying that typedef changed and asked me to revert. Then, saved the class containing the method, and deploy again without success.

btw, If I found quite understandable the revert popup when I've seen it in the past, since I'm working with classes, I feel it nonsense, and poping everytime without reason. There is something to work with Class saving and typedef cash to propagate changes when done.

As far as i'm going to add a lot of items to this Ring as I develop, I would like to be able to run my code each time, and not losing a complete day trying to make it work at each modification.

Maybe something that could help understanding the issue, I have a main VI, wich is the method of a class (using Messenger Library from JDPowell, and its actor class). This main lauches several other actor processes, and I develop all those classes on a project on my computer.

Then, I use another LV project where I declared my RT target and declared only the Main class on it (all other classes are in dependencies). Could this explain something with the updating process of typedef in dependencies?

[Olivier_L]

I just succeeded to deploy my Vis again.

I'm not sure of what I've done, but I guess I closed my project, open only the class with the method not succeeding to deploy.

Open the method and I did a CTRL-Shift-Run (wih no hope as I already did a lot of mass compile before).

Then the VI was marked as changed so saved it.

And I could finally deploy my main VI with success

[F1Nick]

I thought I'd post this here as it might help someone that's tearing their hair out like I was!

This became a problem for me last week which I now think was caused by the most recent update to LabVIEW 2017 (early June?). In the end I was able to fix this by clearing the compiled object cache, as described here;

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8ejSAC

[Hooovahh]

Still an issue with 2018.  I reopened a project I'd opened many times before that is relatively simple with I think only 3 or 4 classes.  Run failed pointing to a VI that wasn't broken.  I started disabling parts of the code until it would run, I was done to a single build array node.  If I disabled it it would run (but not run right of course I needed that node).  I then created a new build array, and it would fail.  I added always copies, moved functions around tried all kinds of things.  Eventually I got this VI to deploy by using an array constant and a replace array subset giving me the same functionality.  But then other VIs wouldn't deploy and disabling a single IPE structure meant it would run.

I cleared compile cache, restarted RT, disabled RT startup, restarted LabVIEW, forced a recompile, nothing seemed to work.  I did rename the offending class and it ran fine.  I renamed it back and it was back to not running.  I was getting ready to format my controller when all of the sudden it started working after a few more restarts and clearing compile cache.  The code isn't the problem, it is how LabVIEW is using the code.  Possibly constant folding being too aggressive, or some other compiler optimization.  When it happens it is on that system, and it is hard to convince LabVIEW to deploy it right.  Is there some INI key that forces a more full compile or deploy operation?  A quick search didn't find anything.

[Olivier_Labo]

For people reproducing this behavior, do you eventually use "Simple error Handler" in your code?

I'm facing again this behavior, and I'm trying hard to workaround it since several hours without success, but here is what I've discovered, and I wonder if that could get a clue :

When I run my RT VI, I have a VI failing to download. This VI is from  a class in a framework, that I never changed, wich permits to load dynamically all processes I'm developing.

Trying some Mass Compile, Clear Compiled Cache, rebooting targets, and so on, after reinstalling one of my target, I've seen the failing VI broken (where it was never broken before).

The broken arrow was claiming that one of my VI was broken, but it was a VI that is inside a "Diagram disable structure" in the disabled case, so it should not have impacted any calling VIs. Whatever, I removed it and the failing VI was not broken anymore (but still failing to load).

I then realized that if I open the Error List (Ctrl+L, or View>Error List), I have some VIs coming from the Simple error handler wich show not supported function for specified target (even if the arrow is not broken).

Those particular functions are in Conditional disabled structures and should be disabled for RT Targets. But with the behavior I've seen just before where a VI was broken because of a bad VI inside a disabled structure, I'm wondering if this could get a source of the issue, where in certain conditions, LabVIEW sees those disabled functions as if they were not really disabled ??

Thanks for your feedback.

[Olivier_L]

Hi All,

My last message disappeared, so I put a simplest one.

I wonder if some of you are using "simple error handler" in their code?

Looking at error List (Ctrl+L or View>ErrorList), I've seen that some VIs from Error Handler appear in Error for being not supported for current target.

Those functions are inside "Conditional Disable Structure" and are disabled for RT targets, they should not be a problem here.

But I get an issue with a VI that is failing loading to the target and doing lots of manipulation, I finally succeeded to see it really broken, and this was because of a broken VI inside a "Diagram Disable structure", so I should not have seen the broken arrow in this conditions.

Then, I'm wondering if that could be a clue or not.

Another point, is that I regularly see some ogtk (OpenG toolkit) VIs being saved with my project, as if they were continuously changed. Do you use this kind of VIs ?

For the moment, I'm again having hard work on trying to get my code downloadable, without success for 2 days now. I thought I found that I had effectively changed a typedef, but even removing it, resynchronizing it, and lots of other Clear Cach, Mass Compile, don't permits me to launch my code again.

My code is working weel on a computer and on a PXI-8106 but don't want to load on cRIO-9082. (I use the same code, but in 3 different projects, one for each target)

[Olivier_L]

Other observations:

- Recently, when facing this issue, I was able to workaround the issue by Building a real-time application, run it at startup, then, loading the code in debug (stopping the RT exe) was making the load successfull.

For now, I'm completely out of ideas to get out of this situation.

- I also realized that I often have a popup when I want to close my project, saying that some VIs are stil lrunning on the target, and asking me if I want to close them or disconnect.

But my code is supposed to close all modules it launch, and this popup should not appear.

Is there a way to know wich VIs are still running on the target?

Do the use of lv classes could explain this kind of behavior? (maybe something staying in memory)

[benjamin-hinrichs]

I wasted my whole day trying to deploy to a Linux cRIO system code that works fine on PharLap and Windows. It would be great if NI "engineered ambitiously" (TM) and sorted out something that wastes people's time for a decade, specially if it is hard and obscure! </rant>

What I tried (many times in different orders):

* Clear compiled object cache or deleting cache file manually

* Countless restarts of LabVIEW and cRIO

* Remove dependencies from project

* Deploy only offending the offending file. In the end I was failing to deploy a VI with just a constant and an indicator (inside a larger lvlib)

* Reverting to prior versions of the project without the offending library (deployed fine)

* In my case it appears to be related to code in a specific lvlib (a DQMH module). If I remove that specific DQMH module and keep others, it works fine (so cRIO should be fine). Also deploying that same code to PharLap works fine. Module also compiles fine, exe deploys and runs (that will be my non-debuggable solution if nothing else works)

* I also notice (as others in this thread) that when I close my project after deploy, that it remais open behind the scenes (though an abort VI dialog doesn't list anything as running). When closing LabVIEW welcome screen, I'm offered to save my project and sometimes some other files.