LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI possibly causing "low memory" issue

Solved!
Go to solution

Hello all.  We have been running a program that logs voltages and temperatures.  The program writes to an excel every second.  While the excel is growing in size, our PC should not be getting "low memory" messages from this.  Attached is a snippet of the program.  This snippet is obtains the temperatures.  The channel writer sends these temperatures to state machine that does the logging and other functions.

 

Also attached is a sub-vi that puts the temperatures into a certain array format that is viewed on the UI.  I am wondering if this sub-vi is making any contribution to the "low memory"  message we are getting.  The sub-vi is designed so that it can be used in other programs and will allow us to get our desired display format without having to manually program array structures.

 

However, I do believe I read in the forum that changing an array dimension programmatically makes copies of the array.  The controls of the sub-vi allow us to change the array dimension by changing two constants, but the indicator array is set as an 8x2 array.  Does the sub-vi make a copy of the array each time it executes if we changed the dimension once?

Download All
0 Kudos
Message 1 of 8
(2,101 Views)

We probably need to see the rest of the code. Where is the stream received?

 

I am not sure why there is so much dead garbage code in the subVI, but that's still not the source of you memory problem. I also don't understand why your dimensions are not blue. Not sure why you even need the subVI.

 

What the array size of the orange wired coming in? What are the correct values for your controls?

0 Kudos
Message 2 of 8
(2,033 Views)

Main VI attached.  In answer to your questions:

 

Where is the stream received?

-Please explain what you mean here.

 

I am not sure why there is so much dead garbage code in the subVI, but that's still not the source of you memory problem. I also don't understand why your dimensions are not blue. Not sure why you even need the subVI.

-The "garbage code"  was my initial attempt at creating a 2D array.  I just never got rid of it.  The part that works was given from this forum.

-As for the dimensions not being blue, what do you mean by this?

-The subVI is meant to be modular, so I can use it for future programs.  I wanted to use it to see if it works

 

What the array size of the orange wired coming in? What are the correct values for your controls?

-The main VI has this set as 10x3 (this is the 2d array dimensions array).   The correct values are 10 for rows and 3 for columns.

0 Kudos
Message 3 of 8
(1,996 Views)
Solution
Accepted by topic author Dhouston

Thanks for the VI. I think it needs some work before it is usable. You have conflicting enums wired to the state shift register, so it is not entire clear what the states are. You initialize with an enum containing eight items, while later you are using a completely different state enum with four items (guessing, because you did not attach the typedef of that).

 

In the earlier code you were writing to a buffered stream on the lower left, but you did not show the other endpoint, it just ended in a broken wire. If the other side never reads the stream, you'll eventually run out of memory. Thus I was asking where the stream data gets consumed.

 

Your "2D array dimension" must be integer and thus should be blue (I32), never orange. You cannot have an array with 2.5 elements! I am not sure why you made it DBL.

 

So if I understand you right, the array has 31 element, where the one at index 15 has a special purpose and needs to be handled separately. Is this correct?

 

Note that your subVI does not really simplify anything, because "delete from array" can already give you the deleted element at index 15. (Here's how it could look like without the subVI).

 

altenbach_1-1597896214098.png

 

Message 4 of 8
(1,977 Views)

Thank you for this information.  Oh wow, so I didn't even need to use a SubVI.  I could just do the code you showed.  That will make things simple for future use.

 

Attached is the typedef I had used.

 

Yes, you are correct about the 15th element having a special purpose.

 

Concerning the 2D array dimension being DBL, the issue was that it would truncate the temperatures and not give us the decimal part.  So if I make it an I32, is there a way to gain the decimal part of the temperatures?

0 Kudos
Message 5 of 8
(1,957 Views)

@Dhouston wrote:

Concerning the 2D array dimension being DBL, the issue was that it would truncate the temperatures and not give us the decimal part.  So if I make it an I32, is there a way to gain the decimal part of the temperatures?


Well, not after you've transformed it. But when it's orange (double/float) you can do a Quotient and Remainder with 1 to get the integer and decimal parts.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 6 of 8
(1,946 Views)

@Dhouston wrote:

Concerning the 2D array dimension being DBL, the issue was that it would truncate the temperatures and not give us the decimal part.  So if I make it an I32, is there a way to gain the decimal part of the temperatures?


The data of the array is DBL, the size is integer. Completely different. I am only talking about the small array that has two elements. For the 2D array, all you need is do is set the correct display format. (Personally, I would format it into a real table indicator where you can set the table headers, format, and even different font and background color for each cell. Slightly more work, but more flexible).

Message 7 of 8
(1,943 Views)

Ok, thank you both.  We will utilize this going forward.

0 Kudos
Message 8 of 8
(1,931 Views)