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.
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.
11-28-2006 09:04 AM
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
11-28-2006 09:26 AM
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
11-28-2006 09:31 AM
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.
11-29-2006 03:33 AM
11-29-2006 09:25 AM
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
11-29-2006 09:40 AM
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
11-30-2006 01:38 AM
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
11-30-2006 01:40 AM
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
11-30-2006 08:51 AM
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
11-30-2006 08:53 AM