recording real time data with write to spreadsheet

[justapro]

I have searched the threads and found a couple of ideas but I am not sure they apply to my situation. I am trying to record 7 channels of data in real time to a file that I can open in Excel. I need the frequency of data logging to be at least 50 hz.

I have attached a VI I have made and it shows how I have attempted to use "Write to Spreadsheet" but it is only giving me the first and last data points and nothing in between. I expected hundreds of data points. Can look at the attached VI and give some advice? I need to get this working quickly and it seems like I am very close.

P.S. - If you have any other tips on improving this VI, I'd appreciate them! I am learning as I go!

Message Edited by justapro on 07-18-2007 12:28 AM

[justapro]

I have modified the spreadsheet but it still is not working! I need to take data today and I am not sure what is going on. Can someone look at this and see why I don't have a bunch of data each at a time step of 100ms? See attachment.

[Dennis_Knutson]

With the first example, I don't see what the problem. For the second example, I set 'transpose?' to false to make the columns line up. With that change and the number of rows in the file was equal to the number of iterations of the while loop.

[johnsold]

I cannot see what the DAQ assistants are set to do, but you are only writing an array with 7 scalar values to the spreadsheet every 100 ms. All the inputs to the Merge Signals block are scalars. If you want to record the raw data you need to wire the outputs of the DAQ Assitants 3 and 4 to some king of file writing VI.

Lynn

[justapro]

I looked at the time vector and the samples are seperated by the following times (in ms):

9468

3393

2560

3410

2560

3415

2560

3415

2560

3410

2560

3415

2560

3415

2561

3409

So there's a 9.5 second delay from the 1st sample to the 2nd, then the samples jump from being 3.4 secs apart to 2.56 seconds apart! Everything is moving slowly, the system is only updating when it samples.

[mikeporter]

I haven't the foggest idea! Try putting a probe on the 2D array outside the loop and see what you get. There should be same number of rows as there were loop iterations.

Mike...

[justapro]

I think it has to do with one of my DAQ settings. I had it on continous with 600 samples and a 200 hz sampling rate. I thought this meant that it would just stay at 200 hz but the number of samples is obviously changing things. I changed it to one sample on demand and it went a lot faster. Thanks for the help!

[Dennis_Knutson]

You have a big problem with the speed of acquisition because of the way you written the program and multiple DAQ Assistants. Every time one of the assistants is called, it has to start to configure the DAQ board, start the task. acquire the data, and then stop the task. You should try putting all input tasks in one assistant and all output tasks in another. You should also look at using the low level DAQmx functions. The one thing you really need to do is avoid starting and stopping each task with each iteration.

[justapro]

I will try and reduce the number but I believe that unless I use low-level DAQ I will have at minimum three DAQ Assistants: Analog Voltage In, Analog Voltage Out and Counter In. I am needing each one of these for the program.

[mikeporter]

Actually that was exactly Dennis' point - you need to be using the low-level VIs.

Mike...