netta

QUOTE (Tomi Maila @ May 26 2008, 09:32 PM)

I think it's not a good idea to keep VIs in LLBs when under source code control.

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)

Please please help... I think I'm going to cry.

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 usually do this by creating a Top Level.vi and putting in whatever dynamic VIs I have. Masscompile won't help since LabVIEW unloads VIs during masscompile as soon as they are not used anymore.

The project doesn't help either because the VIs in a project are not yet loaded.

Rolf Kalbermatter

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)

It's very simple if all VIs are loaded into memory.

Open the top-level VI and hit Ctrl-F to bring up the "Find" dialog. Or via the menu, Edit>Find and Replace...

Click the "Text" radio button.

Type in the text to search.

-James

: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)

If you still like to use 821, build it with debug-flag on, and then manually remove the block diagram of all class VIs and VIs inside the exe-file.

You can extract the llb from the exe file by removing the header in the exe-file until you get to the word "RSRC", this is where the llb starts.

Extract it, remove the block diagrams and then put it back in the exe file.

-Mikael

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)

Are al of the VIs actually statically listed in the project, or are most of them dependancies? If the former, do they need to be?

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)

Looking at the code, there is probably an upper bound around 2^30th VIs. But I don't see anything that should limit below that. I have seen 8000 VIs in a project.

You may be running out of memory on your system. Save As is going to require all VIs to be loaded into memory so that all the saved paths (such as paths to subVIs) can be redirected to the new locations.

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)

If you can make the move to 8.5.1, I would say go ahead. Obviously, you know your situation best and can determine if you can update without impacting your project.

Regarding your dependency question, I would expect that 8.5 would have picked up the dependency better than 8.2.1 did since it does automatic dependency tracking whereas it was manual in 8.2.1.

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)

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)

Thank you for the additional information. What I've typically seen regarding error 7 is that there is a library/class/xcontrol that has a link to a missing file. During the build when we try to copy the file, we get the error that the file is missing. Unfortunately, in 8.5, we don't report the file that had the problem (that has been addressed in 8.5.1). I would suggest examining any libraries/classes/xcontrols for missing files. Also, you could try modifying the options in the Additional Exclusions page that deal with libraries.

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)

Anyhow I do think there is a bug somewhere that under some very rare situations tries to create way to many images for some reason. I could not really imagine how one would get into so many pictures or are you happening to use one or more tree controls with many thousend different custom symbols?

Rolf Kalbermatter

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)

Posting the errors you are getting as well as more information about what it is you're trying to build would be helpful.

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:

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)

No it's likely not really a normal memory error but the image.cpp error would indicate that the image manager somehow got his table of possible image IDs exhausted. Any image in LabVIEW is allocated as an entry in a table and I think the index into that table is really an uInt16. So the table can't get bigger than 65535 images. I can't say what might cause the application builder to create so many images during a build but maybe the GOOP geeks might have some ideas.

Rolf Kalbermatter

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...

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)

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 ).

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...

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

I have a couple of suggestions.

My first option would be to upgrade to EndevoGOOP3 class templates, using the GDS function "Convert Goop2 classes to Goop3...".

If you can send me the code, I can help you out in converting it.

I guess it's not a memory problem but if you're running LV 85, you could increase the memory from 2GB to 3GB for LabVIEW to use.

Since Windos normally limits an application to use only 2GB.

You do this by adding the /3GB swith in the c:\boot.ini file, like this:

[boot loader]timeout=30default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS[operating systems]multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect [b]/3GB[/b]

You could also try to build the executable with the "Enable debugging" mode on, if you are running LV8.5.Cheers,Mikael

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:

Error 2 occurred at Property Node (arg 1) in ABAPI Dist Chg and Save VIs.vi->ABAPI Dist Build LLB Image.vi->ABAPI Copy Files and Apply Settings.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: Memory is full.

=========================

NI-488: No Listeners on the GPIB.

Property Name: Help:Document Path

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:

Any suggestions would be very very welcome....