netta

QUOTE (Tomi Maila @ May 26 2008, 09:32 PM) I completely agree but I have no choice (or so I thought until I went back and had a furtle in the GOOP2 wizard) since our entire development is based on GOOP2 which stores classes in LLBs by default. One LLB per class. Now, having raised this again, I went back and had a good old furtle in the GOOP2 wizard menus and it seems that you can indeed work in directory mode rather than the default LLB mode. Sigh... Wish I'd known that before. I've now got to work out how to do that for the entire project but that's just a scale problem. Anyways... The reason I ask is because I don't have the profession edition of LV so don't have access to LVMerge. I'm trying to figure out whether it's worth upgrading. Cheers.

Hi Folks, I've seen a couple of posts mentioning PushOK's SVN integration. Does anyone out there have any experience of using their CVS integration? I'm using TortoiseCVS at the moment which is fine (although badly lacking diff/merge facility, see My other post re: LVMerge and LLBs). Any comments on your experience, good/bad, would be very welcome.

Hi Folks, I have my project in CVS and am considering upgrading to the professional version of LV to take advantage of the SCC integration and the rather lovely looking VIMerge tool but does anyone know if the VIMerge tool will deal with merging or diff'ing LLBs? If not then it's nigh on no use to me as virtually all my VIs are GOOP2 classes stored in LLBs.

QUOTE (netta @ May 1 2008, 04:08 PM) Well I had got it to build once in 8.5 but turned out it was a one-off fluke... When I tried again it failed and has been failing ever since with file not found errors. I've pared it back to the bare minimum and am gradually adding classes back in (that's GOOP2 classes) in the attempt to find what's going on. It seems that it will fail once and then I run the build again (no changes) and then it will succeed. Then I add in another class, it fails, then I try again (no change) and it succeeds. I have already mass compiled the entire code set and it all compiles fine but it seems that there must be something else that the application builder is doing which "makes things better" so that it works on the second pass. Of course this is only a hypothesis since I have no explanation as to why this happens (and it's not entirely predictable). Any clues? Also... In parallel, I'm still trying to build on 8.2.1 (since it used to build ok up until the latest source release which started failing with the "Memory if full" error... hence the attempt to upgrade to 8.5). So my assumption is that there is something in the latest source which is causing the problem. Again I've pared back to the previous source version which built ok and am gradually adding the new code to try to find the culprit. I've now started to get the following new and exciting error: "Fatal Internal Error: "prim.cpp", line 4851" which crashes LV. Anyone seen this before? :headbang: - wonder how long it'll take for the bruising on my forehead to heal?

QUOTE (rolfk @ May 8 2008, 06:20 PM) I know this is the recommended technique but I have over 100 GOOP classes (over 2000 VIs) so putting them all in one top level VI is not something I relish doing I wonder if I could do this programmatically? In fact solving this would also help with finding usages of VIs which is also not possible at the mo unless everything is in memory... And then there's also the question of whether there's enough memory to hold it all in.

QUOTE (James N @ May 8 2008, 04:06 PM) :thumbup: Thanks James.. Can't believe I missed that... I feel an utter fool now Now I just need to figure out how to get all my dynamically called VIs into memory at the same time so that I can search them.... hmm... Would a mass compile do it or does it unload the vis once it's done with them?

Hi Folks, Does anyone know a way to search a large collection of VIs for a piece of text defined in a string constant? I have an error message being logged from my application which has a piece of text which I suspect is declared statically somewhere but I have no way of finding where it's coming from. In a text-based language this is easy... In LV... not so obvious. Any suggestions would be very welcome. Cheers, Netta.

QUOTE (MikaelH @ Aug 27 2007, 09:18 PM) Hi Mikael, I just found this posting and am intrigued by your suggestion... I may be being dense here but how do you physically go about extracting things from the exe? Surely you don't mean hacking it with a text editor? -- Netta

QUOTE (crelf @ May 6 2008, 12:23 PM) Interesting point... There are certainly more than just the dynamic VIs listed statically in the project but the majority are still the dynamically called VIs (ie the GOOP2 classes). Is there a limit? Also... if it does need to load them all into memory, does it use virtual memory correcly or would it barf if there's not enough RAM?

QUOTE (Aristos Queue @ May 5 2008, 10:30 PM) Thanks Aristos... That's good news on the upper limit. As for the SaveAs, if that's what's needed, why does it not just get ona nd load them or at least give me an error to indicate that it can't? It does seem to being a fair bit of work when I select SaveAs but then finishes with no errors and no output Is there something I can do to force it to load them all into memory?

I have a very large project with thousands of VIs. If I open the project and select "Save As" to save a copy in a different location, it appears to complete but no copy is produced. I have tried with small projects and it works fine. This is LV8.5 and it shows no errors and gives no indication of failure. Also, I have searched the C: drive to make sure it hasn't put it somewhere else

Hi Folks, Does anyone know if there is a limit on the number of VIs which can be included in an LV project? Cheers, Netta.

QUOTE (gmart @ May 2 2008, 01:27 PM) Thanks for the advice. Since I'm only just trying out the upgrade to 8.5 from 8.2.1, I may as well just go to 8.5.1. Hmmm... can't seem to find a download for 8.5.1 on the LV web site. Has it actually been released yet? QUOTE (netta @ May 2 2008, 02:41 PM) Thanks for the advice. Since I'm only just trying out the upgrade to 8.5 from 8.2.1, I may as well just go to 8.5.1. Hmmm... can't seem to find a download for 8.5.1 on the LV web site. Has it actually been released yet? Oh.. just found this... http://www.ni.com/support/lv8_51.htm. I suspect our 1year SSP has expired

QUOTE (gmart @ May 1 2008, 10:46 PM) Hi gmart, As far as I know, we don't use any xcontrols in the project. It's a GOOP2-based project so there's loads of llbs which are all explicitly included as support files to be dynamically loaded. In fact what I do to build the project is drop the entire source tree into the project folder and then I have a little tool which post-processes the .lvproj file to remove the .vit files. I've been using this for ages and it works well and helps avoid missing files. Is it possible that a dependant file outside my source tree may be required which may have been picked up automagically in 8.2.1 but for some reason is not being picked up in 8.5? The problem is, we have around 2800 files in the project so hunting through this for missing files without any clues of where to look is not a very attractive proposition. If you say LV 8.5.1 does report errors better in this area, perhaps the thing to do would be to go straight to that rather than transition via 8.5 Whadayathink?

QUOTE (rolfk @ May 1 2008, 09:02 PM) V Interesting... Unfortunately we're not really using anything even remotely image intensive. We do have a couple of activeX browser controls but again I wouldn't expect these to be anything to do with images. It's quite possible that the image.cpp error and the build failure are completely unrelated. It's just that they have both started happening recently and they both seem to be related to memory issues which made me suspect a connection. To add to this, I've just tried to rebuild with the debug option enabled following on from MikaelH's suggestion earlier on since I was also seeing the duplicate filename warning during the build but that has also just failed with the same "File not found" error. It would also be helpful if it told me which files it thought were duplicate names. It seems to indicate it is about to list them with a ":" but then no list is to be seen Netta sad

QUOTE (gmart @ May 1 2008, 09:26 PM) My omission... I should have mentioned that my world of pain is under discussion at: http://forums.lavag.org/memory-is-full-No-Listeners-on-the-GPIB-t10706.html&pid=45096&mode=threaded#entry45096' target="_blank">Memory full... (didn't want to bore people by replicating it here)... Doh! Also, George, unfortunately all I get after the hour-or-so that it takes for the application builder to get to the point where it fails is a window with the following error: Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference: Error 7 occurred at Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer. ========================= NI-488: Nonexistent GPIB interface.Method Name: Save:Target Instrument Since the call chain is inside the application builder code, it's not very helpful. Neither is the fact that it knows that it can't find a file but doesn't bother to tell me which of my 2800-or-so files it is?! So this was kind of a stab in the dark to see if there was any kind of log written by the app builder so that I could at least se what it was trying to do when it failed.... Is there maybe a flag I can switch on which will write out progress as it goes? Any help would be very very welcome. -- Netta

Hi Folks, I've been having nightmares with the application builder in 8.5 (and 8.2.1 previously) and was wondering whether anyone knows if theres a way of getting it to write out some kind of progress log so that i can find out why it's failing. Ta lots, Netta

QUOTE (rolfk @ May 1 2008, 08:17 AM) Hi Rolf, I've just tried and failed to rebuild the project in 8.5 and get the same error after it crashes so your suggestion about the fixed-size image table seems to still exist... c:\builds\penguin\labview\branches\Jupiter\dev\source\manager\image.cpp(6852) : DWarn: You filled the image table $Id: //labview/branches/Jupiter/dev/source/manager/image.cpp#45 $ Is there any known way of telling labview to ignore the images eg. icons etc... since I only need front panels available in only a small handful of VIs (all the rest are purely background processing) ?

QUOTE (netta @ May 1 2008, 10:42 AM) OK... So I've managed to get the application running in 8.5 (Hurrah!) and so the next step was to try to build the project... It almost gets to the very end but then fails with the following error... Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference: Error 7 occurred at Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer. ========================= NI-488: Nonexistent GPIB interface.Method Name: Save:Target Instrument Does anyone know how to make labVIEW actually tell you which file it is that it can't find (since it clearly knows)?!?! We have thousands of VIs in our application and I can't see any way of finding out what the offending file is. Please please help... I think I'm going to cry.

QUOTE (MikaelH @ May 1 2008, 12:17 AM) Hi Mikael,I would very much love to upgrade to GOOP3 but our project is huge and I anticipate the upgrade to be quite involved. Amongst other things, our object model is dependent on the composite pattern and I gather there are issues related to that in the new version. Once we decide to bite the bullet on this, any help would be very very welcome.Also, we are currently in the progress of upgrading to LV8.5 but are having problems with MSXML (It's happy with DOMDocument but can't find XSLTTemplate... but that's a posting for another thread ).So I guess until we successfully upgrade, my question is... you have any suspicions as to what may be the cause of a "memory full" which clearly isn't due to a lack of physical memory? The image.cpp error does indeed indicate something image related... vi icons?... front panels?... block diagrams?.... are there any ways of excluding these from the build? Alternatively, as you mentioned this configurable memory limit in 8.5, do you know of any other artificial limits (in config in LabVIEW somewhere) which I may be hitting? Ta lots, Netta. PS... forgot to mention we're on 8.2.1 at the mo.

I am at the end of my teather and hope someone out there can shed some light on this... I have a very large project based on Endevo's GOOP2. I have been building it using the application builder with only a small handful of VIs going into the executable itself and all the others going into a support directory (as recommended by other posts on the subject of memroy full errors). My build machine has 4Gb RAM so I can confidently say it is not running out of memory and yet about half way through the build it fails with the following error: I've watched the task manager and there's plenty of free memory... oceans of it. Also it's worth saying that the build does work on my laptop but fails in the same way on two other machines, all with >2Gb RAM. Also, if I then quit labview and restart I get the dialog which says there was a failure and do I want to investigate... The lvfailure log generated contains numerous sections of the form: .\manager\image.cpp(6627) : DWarn: You filled the image table $Id: //labview/branches/Europa/dev/source/manager/image.cpp#47 $ Any suggestions would be very very welcome....