Memory usage/freeze/crash modifying multiple objects

[Beckler]

I'm getting Labview hanging issues when I try to modify front panel objects while editing (not running).  It seems to be a general problem but this is the current scenario.  Many charts on my front panel (over thirty), so I multiple select, and RClick>Properties.  Watching Labview in Task Manager, I watch the Memory usage climb from about 90MB to 600MB.  And it takes a minute at least!  I can then change properties (plot scale ranges), and after more pausing, the dialog closes.  Soon after, I'll get a fatal error and LV crashes.  Something wrong here; I thought maybe it's my computer, but how can it take 0.5GB to load 30 chart property sets?  Core i5, LV2011, Win7.

[Xenox]

Hey,

please post your VI.

[Beckler]

Sorry, can't post it.

[johnsold]

Do you have the chart history lengths set to large values (many MB)?  Do you have significant amounts of data saved as default in the charts?

Try clearing the charts, one at a time if necessary, first.

Charts have internal buffers. So LV may be trying to make backup copies so that you can undo if you change your mind.  Charts are generally not a good way to manage large amounts of data.  I use as a rule of thumb: Do not keeping more data in a chart than the number of pixels in its width.

Lynn

[Ben]

---

@johnsold wrote:

Do you have the chart history lengths set to large values (many MB)?  Do you have significant amounts of data saved as default in the charts?

Try clearing the charts, one at a time if necessary, first.

Charts have internal buffers. So LV may be trying to make backup copies so that you can undo if you change your mind.  Charts are generally not a good way to manage large amounts of data.  I use as a rule of thumb: Do not keeping more data in a chart than the number of pixels in its width.

Lynn

---

I aggree that crashing could be due to the amount of data in the charts. Try clearing them and saving the cleared chart as the default before doing the multiple object selection.

I guess I live a more dangerous life-style that Lynn in that I'll allow more data points than pixels simply because LV is "SO DAMN GOOD" at rendering down the data and supporting zooming. "In the old days" it was a common technique to reduce the data sets presented to charts to avaoid killing the CPU. So Lynn's "rule of thumb" is consistent with history. modern CPU can handle the abuse much better now so I can get away with living close to the edge.

Sharing thoughts,

Ben

[Beckler]

Ok so I tried that--doing a manual "Clear Chart" on each one.  Didn't help.  Memory use grows and eventual crash afterward.  For now I've saved it just after changing everything and before the crash, so I'm ok.  Earlier, I had the levels of Undo set too high so I set it back to 5, and I thought it fixed my freezup issues, but it didn't.   

[Ben]

If you have a "before" and "after" backup and the steps to recreate the crash, I would like to urge you to pass it to NI so they can log a Corrective Action Report (CAR) and get this fixed.

Good guess on the number of un-do steps by the way!

Ben