Are your concerns about your current method of logging being too slow related to the rate of acquisition you are able to achieve? The method you described sounds as though you are doing single point acquisition in a loop and with each update logging that single point to a file. Here are some alternatives to speed the process a little:
1) Perform double-buffered continuous acquisition so that your daq board performs its acquisition task asynchronously in the background of any logging task you desire to do with the data acquired. Look at the example in your ...\MeasurementStudio\VB\samples\DAQ\Analog Input\Continuous Acquisition directory to get an idea of how to perform continuous acquisition. You should pay special attention to the CWAI1_AcquiredData event handler subroutine because this is where you would place your code to log the acquired data to a file. Note that this subroutine is executed as acquisition continues to run in the background on your daq board, so there can be no real complaint about this slowing down your acquisition speed at all.
2) Other than the above solution you could do single point acquisition in a loop and write the data points to consecutive indices in an array. Once the array is filled with enough points you could then write it to a file in the manner you proposed, but acquisition would have to stop in order to do so because processes in VB are executed synchronously. The only real alternative you have to do this asynchronously would be to make a multithreaded app that spawned a new thread once the array hit a certain fill level, and in this new thread wrote the data to a file with the process being continually repeated in a loop: (1)fill array, (2)spawn thread, (3)continue acquisition in main thread, (4)write data to file in second thread. The drawback to this idea is that VB does not natively support multithreaded programming and will crash if you try to debug a multithreaded app in its environment. Also this method is just simulating the first solution I proposed (see #1), but in a less efficient and slower manner, not to mention the multitude of complexities it introduces.
As far as Print# or TextStreams being faster, I don't know, you will have to set up a timing schema to sort that out for yourself. One thing I can tell you though is that you do not have to keep opening and closing the file continually in your app, in fact you might not want to do that at all for the simple fact that it will reset your file pointer everytime you go to write (unless you open only for appending).
Jason F.
Applications Engineer
National Instruments
www.ni.com/ask
