LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP dynamic VI

I have an application whereby I am able to crash the LabVIEW Run Time Engine (8.5).

1. My application consists of a Template VI (which is always in memory) that dynamically loads VIs into a subpanel.
2. These dynamically loaded VIs contain LVOOP classes.
3. In my Build Script in LabVIEW AppBuild I rename my LVOOP class VIs with a prefix (I have no inheritance) in order to try and neaten the build.
4. I build the application (success) and run the executable.

Randomly the LabVIEW RTE will crash when switching between screens (i.e. unloading then loading a dynamic vi into the subpanel). 
Sometimes on the first switch, other times the 50th switch.

Fixes I have found:
1. In the template VI I host an object of each LVOOP Class as a constant of the block diagram. This must keep the class in memory the whole time? As switching between screens in the subpanel is way faster. Seems to be alot of overhead in loading the different classes.
2. Do not rename the LVOOP Class VIs (resulting build structure is more complex) in the build script.

Either solution seems (thus far) to make the Application way more robust.
Of course with inheritance I would be forced to use Fix 2 as with Fix 1 I would have to use the same prefix (which would still cause a name collision etc..).

Question: Is there a known issue with the LabVIEW RTE dynamically loading/unloading VIs containing classes that have a prefixed name? 
If so is this fixed in 8.6 (I dabble in 8.6 at home from time to time but 99.9% of work is 8.5 or 8.5.1 so) I haven't tried with this app.

[Cross Post]

http://forums.lavag.org/Dynamically-Loading-LVOOP-Classes-With-Prefix-Name-in-Executable-t12793.html

 

 

 

 

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 1 of 6
(3,460 Views)

Hi JG,

 

Your scenario sounds similar to some issues I ran into but mine were not intermitant.

 

1) 

In my case I was using template to realize "Active Object" of various classes. At edit time the template were happy but when I tried to run them, they would end up broken. Aristos Queue attempted to exaplin the resoning behind why a VI created from a template that is a memeber of a class is not concidered part of the class. So to avoid the problem, I re-wrote the templates to only use public methods and all was happy. So this was a feature and I just ahve to live with it.

 

2)

At development time if I attempted a "Save as..." on a class that used methods from its parent, LV would return an error (or was it a crash?). The work-around there was to put the code that called that parents method in a diagram disable structure, create the copy, then delete the diagram disable. This was an issue that could not be reproduced in LV 8.6 so no bug fix here. 

 

3)

Another issue was editing type defs taht were part of the private data of a class. This resulted in a crash when the type def was saved. This was reproducable and a CAR was created. I think the work-around was to make sure everything except the type-def was closed when doing the edit.

 

So I don't think I ran into the issue you are seeing but maybe one of the above will inspire you. Smiley Happy

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 6
(3,434 Views)
I have never run into this particular issue, but I can give you a way to figure out where the crash is happening.  Check out my earlier post on race condition debugging.  The code is also very useful for this type of problem.  Drop the monitor VIs liberally in your application.  Run DebugView while running your application.  When it crashes, you will know where in the code the crash occurred (look at the last DebugView entry).  You can then sprinkle more monitor VIs around in targeted places until you have isolated it. Good luck.  I will notify Aristos Queue to monitor this thread.  He may be able to give some better info.
Message Edited by DFGray on 01-08-2009 08:19 AM
Message 3 of 6
(3,409 Views)

Thanks for you posts guys. Smiley Happy

 

Ben - I will have to define my use of the term "Template" as it is what I call my hosting VI (subpanel, RTM, toolbar, status bar etc..) not a .vit (sorry for the confusion). I really like LVOOP but the above was nearly a showstopper! My thinking is the more I use it the more I will learn about it! (Looks like you have put in the ground work with your problems listed!)

 

DF Gray, whilst your VI is great and cheers for the link, the actual LabVIEW Run Time Engine is crashing - not the application.

As far as I know this info is not in any LabVIEW error cluster. I get to view the Windows memory stack, but it was not that helpful (to me)

 

As in my original post, it seems I have been able to solve the problem but I was hoping someone from NI would also be able to comment. 

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 4 of 6
(3,355 Views)

Usually in when I find myself in your situation, I am trying to find my portion of the code which is causing the crash.  The location of the trace VI is then the important thing, not the information it carries.  I usually stuff the input with numbers or some location specific text string.  By looking at what actually executes before the crash, I can find what is executing when the crash occurs.  A "binary" search usually narrows it down pretty fast.  Unfortunately, finding where the crash occurs does not always help.  I have had memory issues where a malformed call library node corrupted the call stack, but the crash did not occur until much later.

 

I am glad you seem to have solved the issue.  Let us know if you need more help.

0 Kudos
Message 5 of 6
(3,339 Views)

Thanks DFGray.

 

The crash was definately happening when I switched screens and a vi was loaded dynamically as a plugin into the subpanel. Altho the the solution(s) posted fixed the problem, I would still like to know why renaming the class with a prefix and loading a vi dynamically which calls the LVOOP class would cause the LabVIEW RTE to crash! 

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 6 of 6
(3,312 Views)