Datalogger to excel for NI 9213

[NIquist]

This all works fine for me.  Here is the code with the correction notated.

[HelpMe9211]

So far the vi runs like it should - (thanks so much) -but I'm not able to include the time stamp into the vi.

Every time a reading is taken it should include the actual time stamp in a column.

[NIquist]

Very simple way.  See green notes.

[HelpMe9211]

I made the changes like you showed - it works!!

I then made a modification to control the sample rate being written to excel. ( ex: 1 reading per minute) but it is causing the excel file to print extra data.

[Dennis_Knutson]

You are not creating an Excel file and you are not doing any printing so you really need to define the problem a lot better.

There is a text file being created and if there is something you don't like about it, then attach the text with an explanation of what you do not like.

edit - looking closer, no matter what, you are writing to the file, even when you are not doing an acquisition. Why don't you simply place the file write functions inside the case statement?

Message Edited by Dennis Knutson on 01-28-2010 09:18 AM

[NIquist · Accepted solution]

The VI I sent is using the DAQ collection time to determine the loop speed, and hence, the resolution of the data collected.  If you change the sample rate or # of samples your resolution will be equal to the # of samples / sample rate.  This was just to get you started in the right direction.  Normally the way to collect data points that are many second apart is to increase the sample rate until the data is collected in a second (or so, depending on your application), then use a timing function to wait until it's time to collect again.  In other words, you could set the # of samples to 1000 and set the sample rate to 1000 samples /second so all samples are collected in ONE second.  Then you use a Wait.vi in your loop to delay the next iteration so that you get the time resolution you desire.  So in your case you could collect 1000 samples over one second, average and store the results.  Then, have a 10,000ms wait in the loop so it won't collect again until the full TEN seconds has passed.

There is an example to show this called:  examples\DAQmx\Analog In\Measure Slow Varying Signal.llb\Acq&Chart Mult Samples-SW Timed.vi

Again, there are much better ways to control timing with LabVIEW than simply putting a Wait.vi in a loop but for now you should stick with the basics. 

[NIquist]

I just noticed your example time resolution of '1 minute' in your last post.  Once you're logging at such slow rates you may need to use more advance timing concepts (such as a state engine).  Putting a long delay (wait.vi) in a loop will mean that you have to wait a minute or two for the VI to respond after you press your stop button.

[HelpMe9211]

Thanks so much for your help - a rookie such as myself greatly appreciates your assistance!!!