[Bug?] Beware of changing your chart inputs...

[kashiruvana]

Forums searches turned up related but different issues, so here goes: is this another chart memory leak or have I missed something?

The problem is simple, although I doubt it shows up often.  If you put down a chart, its data space memory usage should reflect what's needed for the chart history times two.  However, any time you switch inputs between scalars and arrays (doesn't seem to matter what type, or what dimension for the arrays, and I was testing with empty arrays), the chart grabs another whole buffer (history x 2), and the data space grows by that amount.  If you switch back, it grows again.  You can change array dimensions, delete your input and wire a new one of the same "order", or do any number of other things, and the data space is fine.  But any time you make that particular switch, the data space grows.  From everything I've tried, there isn't any way to free up this memory, even by deleting the chart from the VI, except to CTRL+Z all the way back to before you wired any inputs.  If you've closed it or done a bunch of work afterwards, I don't think there's a way to reclaim it, and it doesn't get cleaned up with a restart.

Obviously, this probably hasn't even come up on anyone's radar for a few reasons, but we often deal with very large data sets, and I discovered this in a chart with a 1M-point history.  (On a 32-bit machine, no less.  Why do they even make those anymore)

I have screenshots available if anyone is interested, but I have to cull and crop before they're useful to anybody else so I didn't put any here.  I haven't delved deep enough into VI scripting to find a programmatic way to see the memory usage breakdown--on that note, does anybody know how to do that?--so I don't have any snippets, either.  I'll be stuck in the lab so I will be slow with responses, but I will be eager to hear if anybody has any suggestions or foreknowledge of this.  Thank you!

[Ben · Accepted solution]

LV ahs to keep the history to support "Un-do".

Only possilbe work-arond would be to change the number of un-do steps to zero?

Ben

[Bob_Schor]

I think I understand what you are saying (but am not 100% certain).

Usually when you design a Front Panel and put down a Chart, you decide first what you are going to plot, then wire that to the Chart.  As you know, Charts are polymorphic -- they "adapt" to fit the data that is wired to them.

I think you are talking about the Chart retaining a "Memory of Wires Past" (sorry, Marcel).  I haven't looked for this (and don't propose to do so), but let's assume that is what is happening.  I would definitely think that you could safely do the following to fix this:

1. Delete the Chart.
2. Close the Project.
3. Exit LabVIEW.
4. Restart LabVIEW.
5. Open the Project and the VI.
6. Add a new Chart.
7. Rewire the Chart.

In the Best of All Possible Worlds, you might be able to skip Steps 3 and 4, and maybe even 2 and 5.  However, if the problem persists, maybe you should give an example (code, please, so we can try it ourselves).

Bob Schor

[kashiruvana]

Yes, I think it is a "memory of wires past," as you say.  Unfortunately, your suggestion is one of the approaches I tried and it doesn't seem to work.  When I first saw the behavior, I wrote up a little test plan and went through a bunch of different iterations to see if there were any way to avoid the issue, but I didn't find any (other than the undo-ing).  You can delete everything off the front panel, save the vi as a totally blank block diagram and front panel, fully close out LabVIEW (and verify that my RAM usage returns to normal), but when you re-open LabVIEW and open your totally empty VI, the dataspace is just as big as it was before you deleted anything.

Oh!  Also, I should point out that I'm using LabVIEW 2013.  I haven't tested it in any later versions, although it's simple enough to do so if I can get some time on the computer with 2015, I'll check it out.

Thanks for your suggestions!  Fortunately, I haven't gotten caught by this, at least not that I know of.  We tend to each write all the code for our own applications around here, and we each do all the design for ourselves, so no requirements documents.  Particularly since I have a habit still of coding what one might call "nonlinearly" while I get all my ideas down on the screen, I can see where I might write each sample to a chart and then later decide I'd rather write data in blocks, or some other kind of input change.  It's highly unlikely, particularly for the history to be big enough to cause a problem, but not impossible.

[kashiruvana]

Hmm.  That could be, although do you think it would persist, then, after closing LabVIEW and reopening it?

[Yamaeda · Accepted solution]

What happens if you change Undo steps to 0 and then set it back to what it was (20)?

/Y

[kashiruvana]

I'll give that a shot, thanks!

[kashiruvana]

I apologize for the extended absence.

Yamaeda, it wouldn't let me change undo steps to zero but it would let me change it to 1.  I've played around with your suggestion and here's what I found.  Yes, the problem is in the undo history.  If you set the undo history to something small, those chart history buffers will eventually fall off the back and you'll get the dataspace memory back.  Having not touched the defaults, mine was still set to 99 steps, so all those changes just built up in my undo buffer.  The dataspace memory will clear up even if you save and exit out of LabVIEW--in other words, even beyond when you can access that undo history, whatever's being held in it will stay around until it leaves your undo buffer, but you can clear that at any time by changing the undo size.

I think that, if there is a bug to be found here, it's that LabVIEW seems to consider that there are two categories--scalars of all types and arrays of all types and dimensions.  If you switch inputs within a category, it doesn't keep a dedicated copy of the history buffer in undo, but if you switch across categories, is does keep a dedicated copy.  I'm not sure whether it should be keeping a copy for everything or nothing, or maybe it is actually Working As Intended(tm).

Thanks for the solution!

[kashiruvana]

Oh, and Bob, I had meant to include in my previous response that, you're right, you typically know what you're plotting before you send it to a chart.  Even when I posted it, I didn't foresee it coming up much if at all for most people.  The only reasonable example I've come up with is if you know you're going to read data from a DAQ and plot it but you haven't decided whether you're going to read single samples or blocks.