06-20-2012 09:36 AM
Hi
The attached VI was a pre-written one, so I don't know to much about it and I don't have any labview programming exp. I checked the buffer allocations as suggested and boxes for array and clusters is checked. Also each file that is saved transfer is 13K and sample is 15K. I'm not too sure if that was what you were asking.
I re-ran program yesterday and it worked for no apparent reason, but I agree its badly written and failure can occur again at any time wasting valuable experiment time, so any help is really welcomed.
Thanks
kal
06-20-2012 10:23 AM - edited 06-20-2012 10:25 AM
Nothing sticks out that would use a lot of memory, but as we said in the original thread, this code would really benefit from a major makeover to limit memory fragmentation. Are you sure about the array sizes or could it be that the instruments ocasionally sends much larger amounts of data?
As an example let's have a look at the code of "take sample FFP" and what happens immediately later in the calling VI, starting with an empty array (top of image). All this could be consolidated into a FOR loop that produces the 2D array in one swoop. Simpler and more memory efficient? Yes, of course!

Also look out for representation mismatches. Why is the array input for the "write array to file..." extended precision"?? DBL is sufficient! That coercion forces another data copy, for example. Look for all coercion dots and make sure all subVIs use consistent data types.
This is just the tip of the iceberg lettuce. Judging from the "invert+continue if true" constructs, this program is probably very old (4.0ish?). It probably could be rearchitected using 25% of the current code but it's probably not worth the effort.
If you look at the memory use over time (e.g. with the task manager), does it continually increase?
06-21-2012 05:17 AM
Thanks I'll have a look, There is no distinct increase in memory useage which was what was strange. But maybe the VI needs to simiply be rewritten. I'll ask for help
thanks