RUF,
The fact that some of the code is in a subVI is not the problem. SubVIs have a very small ovehead which is completely negligible in your case.
I see several things which may contribute to your performance issues:
1. You save every other data point to the file and plot the ones in between to XY Graph 0. Is that intentional?
2. You acquire one point at a time (per channel) and then write it to the file. This means about 50 DAQ Reads and 50 writes to file in the subVI, another 50 DAQ Reads and 50 writes to the graph per second. Writing to the file can be quite slow. Writing to a fornt panel graph faster than the user's eye can respond wastes time. Are you keeping up or do you get buffer overflow errors?
3. Performing calcuations inside the loop which never change wastes time. Do them once outside the loop. (1/100 rate).
4. You take scalars, build them into one element arrays, convert to dynamic data type, run two points through the Build XY Graph Express VI (which converts them to wavefroms and then back to arrays), and then plot them on XY Grpah 0. A Bundle node would do most of this in one step. But what is the value of a graph of one point?
Solutions.
1. Define exactly what data you need to acquire, what data you need to save, and what data you need to display. You indicate that loss of data is expensive. What is the most likely cause of lost data? Slow performance of your program? Power interruptions? Something else? Is the data used while being acquired or only after the test are complete? I suspect the latter because you indicate that you could write later if there were no risk of loss of data.
2. Consider a Producer/Consumer architecture for your program. This would have all the DAQ Reads in a separate (Producer) loop. The only other thing in the Producer loop would be a queue or other mechanism to tranfer the data to the Consumer loop(s). The Consumer loop would accumulate the data and periodically write it to the file and update the graph. The loops could (and probably should) run at different speeds. Look at the Producer/Consumre Design Patterns which ship with LV. How much data you read in each iteration of the Producer and how often the Consumer writes to the file and updates the graph depend on the results of suggestion 1. I am sure that the timing you now have is far from optimum.
3. Clean up the loops. Loop Iteration/Sampling Frequency = (1/Sampling Frequency)*Loop Iteration.
4. Shift registers in the Consumer loop will probably be the way to accumulate the data for both the graph and the file. You never need to send the graph more points than there are pixels in the plot. XY Graph 0 has a plot area 624 pixels wide. If you ever send it more than 624 points, LV will compress the data (in some way which is not well publicized) to the number of pixels in the display. So do not send tens of thousands of points to the graph. Insert Into Array can cause problems with memory allocations and speed when used in a loop. Use Initialize Array outside the loop and Replace Array Subset inside.
Lynn
