From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 8.0.1 Runtime Crash w/ Application.exe - Urgent!

OK, after much further debugging, I believe I have it narrowed down, but have no idea how to solve it.

My program makes use of about a dozen or so different VIs running in parallel.  The end-use for this application is image acquisition and analysis (i.e. framegrabber card and camera).  I have a main GUI which loads these "daughter VIs" into subpanels.  The subpanels themselves are contained within tab displays, so that I can have all information contained within a single GUI.  This is the program (DIAAS.exe) which crashes under Win2K.  Everything seems to load, and the instant everything loads (and is placed into their respective subpanels), DIAAS.exe crashes.  Same time, same place, every time.

I created another "GUI" which loads all the same daughter VIs (in the same sequence), except does not contain any subpanels.  So, it loads every VI as a separate instance, in its own window.  Absolutely no changes to the daughter VIs, just removing subpanels from the GUI.  This runs fine on both Win2K and WinXP, whereas the version with subpanels crashes on Win2K.

So, it appears to be something with the subpanels.  My GUI uses a total of 7 subpanels to display 7 different VIs.  These VIs communicate with each other via queues, and are all necessary for the program.

To make matters more interesting, it seems that a more complex directory structure during AppBuild compunds the issue.  For example, WinXP-working version will crash (exactly the same error) when new destination directories are added to the build (i.e. Daughter1.vi is added to \New Destination\ during build instead of being placed in Application.exe).  Again, when not using subpanels, this is not an issue.

I tried setting the subpanel property to "Synchronous" and then afterwards deselecting it, but this made no difference.

Any ideas?  My temporary workaround is to use the version with no single GUI (i.e. multiple windows) to at least get my application operable.  However, I need to get the single GUI (i.e. subpanels) working properly.  Any thoughts?  Thanks!

DJH

0 Kudos
Message 11 of 29
(1,184 Views)

I found this thread which may shed some light on the issue

And in a DOH moment, here is another thread that I was involved in dealing with subpanels and a .exe.  The user had a memory error (which it seems you get too) and the issue was resolved (at least that error, the user had multiple errors) by adding the vis that run in the subpanels as dynamic vis when you build the application.

If i find anything else i will let you know

Kenny

Kenny

0 Kudos
Message 12 of 29
(1,182 Views)

another thought is that if you have the the vis in a diffrent directory than the subvi (the complicated directory structure you were talking about) you might need to do some more path stripping to find the correct location of the vis.  It may only be looking in the subvi/.exe location instead of the real location, a folder or 2 "down" from there.

There are some good examples shipped with labview on dynamically finding the correct location of a vi.

Kenny

0 Kudos
Message 13 of 29
(1,181 Views)
Hello again; some good suggestions, but I had already incorporated them into my design.  I have read the other threads pertaining to subpanels, but did not find "the answer".  As far as I can tell, I am pretty much adhering to the programming rules.
 
I have created a small example of what I am trying to accomplish and have attached it to this thread.  The only difference, is that instead of using the "Abort" function in my sub-vis, I use the "Front Panel Open = False" option.  This generates an error when using subpanels (and I have also tried using the abort), but remember I need to be able to use these same VIs as standalone, and have them close when finished (if I use Abort, this will not happen), and I am not aware of a method to make use of both.  But, I digress...
 
Keep in mind that my program works well within WinXP, but crashes in Win2K.  This being the case, I know where the Runtime VIs are placed, and am accessing their location correctly.  I included this in my zipped example, also.
 
One unusual thing I did notice with my example, is that random numbers are only generated in the sub-vi panel which is active upon startup, but not in the "hidden" subpanel on tab 2.  I have not noticed such behaviour in my real program.  Why is this, and could this be a contributing factor?
 
Look over the example (which is a very small-scale version of my real program), and let me know what you think.
0 Kudos
Message 14 of 29
(1,169 Views)

I saw the same behavior when I ran your program, panel 1 was not "running".  Once I changed the subpanel vis to include a wait(ms) with a 50 constant wired to it, and the same for the while loop in your main vi, the program worked as expected.  This could be an issue with your real program, I dont know.  If it is, it could be that XP handles more threads better than 2k, just guessing.

Maybe check how much cpu and memory the program is using on the 2k machine, with the gui that uses subpanles and the one that opens them in all different windows to see if there is a difference.

I attached the vi that i modified that is working (running both subpanels at once).

Kenny

Kenny

0 Kudos
Message 15 of 29
(1,159 Views)

 may have misunderstood you, but it sounded like from your last post that you wanted to remove the vi from the subpanel if it was done, but still be able to have it running in case you need it again.

 

i modified the program again to try this.  the subpanels will stop at 100 iterations and 200 interations, i only have panel 2 removed and reinsterted.

Kenny

Kenny

0 Kudos
Message 16 of 29
(1,157 Views)

Hi Kenny;

Not quite... I basically just wanted to provide an example of how I am using subpanels within my system.  In each of my VIs contained within the subpanel, there is no issue with them working, as I actually do have while-loops with timeouts wired, although it makes sense to add them to my example.  But my main concern is that I am using the subpanels correctly, and that the lvproj file is set to build the application correctly.  As mentioned in an earlier post, I am sure that my file pointers are set correctly (i.e. inside the DIAAS.exe or destination directory for runtime, and as per regular directory structure for Development mode), and since this works fine in WinXP, I am sure that this is correct.

Also as mentioned, I can get DIAAS.exe to crash in WinXP if I include an extra destination directory (on top of the ones I already have).  At this point, it is an educated guess that the subpanels are the culprit (I do use 7 of them in a single GUI, separated by a Tab structure, similar as in the provided example), as this is the only difference between my Win2K working and non-working versions, and in my individually-windowed version, I can have as many destination directories as I want, with no hint of crashes.  Any thoughts?

DJH

0 Kudos
Message 17 of 29
(1,150 Views)

Oh, and to answer your other question, there is no appreciable difference in CPU usage between the two versions.  Percentage-wise, they are both relatively low.

DJH

0 Kudos
Message 18 of 29
(1,147 Views)

I looked through the LV 8.2 readme and found

LabVIEW returns out of memory errors when a VI built in one version of LabVIEW calls a DLL that in turn calls another DLL built in a different version of LabVIEW.

Not sure if this is the case.  I am assuming that you have mass compiled all of your program to upgrade it to 8.2, if you are sticking with 8.2.

I tried to run the example that you sent me on a 2k machine and i did not get any errors, unfortunatly.

I will see if I can come up with anything else.  If your code is not propietary, would you be ok with posting the code so that I can try it on some of my computers and/or look over the cod eto see if I can come up with anything.  I completely understand if you do not want to post it.

Kenny

 

 

Kenny

0 Kudos
Message 19 of 29
(1,140 Views)
I know that you seem to have narrowed down the problem to something with the subpanels, but I was just throwing out the dll issue.
Kenny

0 Kudos
Message 20 of 29
(1,140 Views)