Maximum program size

[dogface]

I would like to know what the limitations on size is for a LabView 6.1 application. I have seemed to have hit a limit at 11,997 KB. It could be a sub item (such as a maximum number of property nodes, or loops within loops) limit that I have unknowingly reached. Could it have some relationship to hardware, such as installed RAM or size of SWAP file, or the number of processes running at the same time?
I only have about 25 percent of my program written, so I either need a way to write larger programs or I will have to totally re-think my program.

[EdDickens]

What kind of problems are you having?

Most likely you're running into memory problems, especially if you have any large arrays in your application.

I've never heard of an internal LabVIEW limit on application size or number of various items in the application.

If you're running Windows2K or XP, try opening the Task Manager, and on the Performance tab, see how much memory is available with your application open.

You might also want to look at other issues like Spyware or Virus infection. Either of those can have bad affects on a system.

Ed

[ralfseidelXXX]

I actually have the same problem that there seems to be a limit for the maximum size of an array. For example if I initialize an array (U8 - bute) of 200x200x5000 (about 200 MB) than I get an error message that there is not enough memory. However, I have 1 GB RAM and there are typically 800 MB free according to the system monitor.

Ralf

[tst]

Are you sure the problem comes from initializing the array?
Is it possible you're also making copies of it (locals, coercion and so on)?
Which LV\OS do you use?

[ralfseidel]

I don't think I make up copies because for smaller arrays the consumed memory (from the system monitor) fits well with the size of the array.
The Labview version I use is 6.1

Thanks,

Ralf

[DFGray]

In LabVIEW, unless you know exactly what your are doing, you will make copies. LabVIEW 6.1 is worse about this than LabVIEW 7.0 or 7.1. I would strongly suggest you check out the tutorial Managing Large Data Sets in LabVIEW. It should give you the info you need to survive. In particular, single-step through your code with an eye on your OS memory monitor (Task Manager for WinXP or Win2K). Your version of LabVIEW is old enough that a buffer viewer has not been released for it.

Note that LabVIEW typically gives an out-of-memory error about the 1GByte mark under Windows. This is a Windows OS limitation. LabVIEW itself could probably handle about 2GBytes of total memory (32-bit program).

Good luck. You can probably do what you want to do, but it won't be trivial. Let us know how you make out and we can offer more help, if needed. Code would be very helpful for debugging.

[Ben]

Hi DF,

Well I have run into this issue and am going to sit down and read your article in detail as I had previously promised myself I would do.

Thank you for writing this article and repeatedly posting regarding its existance.

Talk about answering my queestion before I asked it!

Again, Thank you!

Ben

[Ben]

Hi DF et al,

I have digested the article and would like to ask a follow-up Q. I hope you or someone else can offer some guidance.

You said

"
When routing data through subVIs, make sure all front panel terminals are on the root of the block diagram, not inside a case statement, loop, or other container. The memory copy algorithms generate more copies if the terminals are not on the root.
"

1) I have to confess that I have never heard the term "root" applied to a block diagram. What didn't I read that talks about the root?

2) If I ran RT would I still see this limit (RTX?)?

3) If I busted the application in half and ran one half as an exe and the other half in the devlopment environment, would the two applications map to sepearte memory spaces?

4) Could I run half under Windows and the other half as RTX (provided #2 is true)?

5) Could I serve VI's from VI's from a number of exe's to get around the limit using a divide and conquer approach?

6) If I have to resort to a bunch of distributed platforms that monitor sub-sections of the application, VI server may be useful in exposing my LV2's to the GUI machine. Does a VI that is invoked from another machine using "Call by referce' method (on the calling machine) run in the UI thread on the serving machine?

7) Do you know of any way to determine in which thread a section of LV code is running in (So I can answer Q's like #6 myself)?


If you have read this far thank you!

Here is some background.

My application will utilize a shared memeory interface to monitor the performance of a new "Widget System" (WS). The WS is composed of set of interacting nodes that use the distributed shared memory to coordinate their operation in real time. I have to record all the interactions, time-stamping each event that occur during each test.

I am handling the above requirements using a special LV global that only replaces the elements that change.

THe shared memory space has been broken down into tables with each table being handled by an an appropriate "expert" that understands how to handle the details associated with the table.

I plan to set up one LV2 for each table so that I can use disimilar "sample rates" for each table (This may end up being my ticket out of this mess!). This will let me re-allocate memory that would have been wasted when one of the tables needed to be sampled at a higher rate.

One of the big requirements of this project (show stopong big) is that the data MUST be kept in volotile memory and can NOT be written to disk until all security requirements are met.

So no writing to disk until everything is done. No, no temp files.

THe other requirement which may be flexible is 1000Hz sample rate for minutes at a time.

Last question for now,

Does the Mac OS have this same limit?

Thanks for reading!

Ben

[m3nth]

---

@Ben wrote:
Hi DF et al,

I have digested the article and would like to ask a follow-up Q. I hope you or someone else can offer some guidance.

You said

"
When routing data through subVIs, make sure all front panel terminals are on the root of the block diagram, not inside a case statement, loop, or other container. The memory copy algorithms generate more copies if the terminals are not on the root.
"

1) I have to confess that I have never heard the term "root" applied to a block diagram. What didn't I read that talks about the root?

---

Hi Ben, followed you here from your other post. Sounds like you're going to have quite a bit of fun writing routines with that much data. 🙂

Most of your questions are beyond the scope of my experience but I thought I'd comment on the one item that I could understand.

The "root" of the block diagram is not a technical term really and I have never read it before either, it just makes sense from a nesting point of view. Anything on the block diagram that isn't nested is in the "root" or highest level of the block diagram and is processed only once each time the VI is called. Since it's processed only once it uses less memory which you already know, but in essence "root" just means "not nested".

[Ben]

Thank you for the reply m3nth!

I had one developer working non-stop for two weeks just to define all of the type def's.

And as you can tell from my questions the real fun starts now.

I agree with our reading of the term "root". I would also not be suprised if this term is related to LV scr___ing as viewed from the back side (NI view point) of what we "give" to the devlopment environment.

Still trying to expand my knowledge base,

Ben