Write to spreadsheet problem

[Crashdx]

I am having an issue with my data recording. My previous issue was that I was unable to get my data to record at a minimum of 1 ms, but I have solved that issue for the most part. I have been able to get my data to record every 1ms, but I've been getting an error in my data where I'll get a set of numbers where none of the values change. This shouldn't be happening because the data is continuously changing. I have attached a sample of spreadsheet along with the code and the actual spreadsheet(which probably won't have to be looked at). I'm using an NI Elvis as my DAQ device.

[Dave.C]

Hi Crashdx,

Does the number of times your inner loop executes equal the number of rows in your spreadsheet?  If so, It may be the case that you're reading the same value on the input channel for several iterations of the loop.  It looks as though the time being logged is changing so it's likely this is the case.  

Have you tried changing the input channel to see if the behavior is the same?

If you slow your loop iteration speed down, do you see the same behavior?

[Crashdx]

My inner loop is suppose to record all 4 values for every iteration. 

My problem before this was that I wasn't going fast enough and that I couldn't go below 20ms without the program recording inconsitent time values. When it is slowed down to 20ms per iteration this issue does not arise.

I attempted to change the input channel, but it gave me the same results. I also tried to remove one of the rows(raw data) and even with three rows I get the same results. I'm wondering if it has something to do with the way my code is running, but it's happening when no big changes are happening in the code. it should just be directly reading the values and inputing them to the spreadsheet.

[Dave.C]

This might be related to your hardware.

Are you using the original ELVIS board or ELVIS II?

What DAQ card are you using in your computer?

[Crashdx]

I'm using the NI Elvis board and the daq card is "National Instruments PCI-MIO-16E-1 10721EE 183455H-01".

[Dave.C]

The PCI card should certainly be capable of sampling at the 1 msec rate.

Have you tried running one of our prebuild examples to see if it works with that code.

I'd recommend trying the Voltage-Continuous Input.vi example.  You can find it in LabVIEW by going to Help»Find Examples»Hardware Input and Output»DAQmx»Analog Input.

Let us know if you see similar behavior with this example.

[Crashdx]

I was unable to find that example, but I ran the example version of the code I'm using to keep track of my optical encoder. I used the Count Digital Events code and I modifyied it for this test just so it would record the data for me. I got similar results even though it had no other operations running. I've attached a segment of the spreadsheet to show what it is outputting and the modifyed code as well.

I would also just like to say thank you for all of your assistance so far. It is very much appreciated.

[Bob_Schor]

The problem is that you are doing everything in a single loop, including sampling the data, writing to the spreadsheet, doing calculations, and outputting voltages.  The loop cannot run any faster than the slowest operation.

LabVIEW is very good about supporting parallel loops that operate "in parallel" (or close enough that you can't tell the difference).  You have a classic Producer/Consumer situation -- you are Producing samples at 1 KHz, and need to "Consume" them at that (aggregate) rate.  However, you don't need to Consume a point before you Produce the next one!

Ignoring, for now, the Analog Output part of this problem, let's simplify it to "I want to take data at 1 KHz, save all of it to a Spreadsheet, and produce two graphs when all of the data have been collected".  You can find a sample Consumer/Producer pattern by going to File/New and choosing Create New from Template, Producer/Consumer Design Pattern.

Basically, what you do is to create a Queue to hold the data.  In the Producer loop, you put the data on the Queue, and you're done (this takes essentially no time at all), letting the Producer loop run at the speed of its slowest element, the 1 KHz sampling clock driving the A/D converter.

A separate Consumer loop takes the data off the Queue and does whatever you need to do with it, such as writing it to a Spreadsheet.  I can imagine that getting this process started (opening files, etc.) could take some time (maybe even as long as a second, 1000 samples), but once things are ready to go, writing a single sample should be (relatively) quick, and the queue-emptying Consumer loop will "catch up" to the Producer.  [Needless to say, you need to make the Queue long enough, but if you take the default queue length of -1, or "grow automatically as necessary", this should work for you].

Good luck.  Let us know if this solves your problem.

Bob Schor

[Crashdx]

Thank you for the response. I went ahead and set up a simple version of my code just for the data recording section using the producer and consumer loop. I'm not positive if I set it up right, but I believe i've followed the structure properly. Unfortunately I am still getting the same issue. My data points will stall at the same value for over 15 iterations. I've attached to code to see if I layed my program out properly or if I have another issue.

I'm only feeding in the data and no the time because at this point I just want to look to see if the data itself is being recorded properly.

Thank you all again for the assistance.

[Bob_Schor]

There's nothing that seems obviously "wrong" with your code.  Here are some suggestions to narrow down the source of the problem:

• Try running at 100 Hz by wiring 10 into the Wait.  Also, note you should use a Wait for Next Multiple (looks like a metronome) if you are trying to get a loop to run at a specific period.
• Wire "False" to the Case Statement in the Producer loop, and make the False case to simply put the index, "i", on the Queue.  You should see 1, 2, 3, 4, 5, ...
• Simplify the Consumer loop by taking out the time-intensive step, writing to the Spreadsheet file, and see if the numbers look like they are changing at the correct rate.
• A minor point -- it looks like you are putting a single U32 value on the Queue (it comes from your Counter).  When you create the Queue, you do "something funny", wiring an array and using the Array Size output as your Queue Type.  Instead, go to the Numeric Palette, find the blue Numeric Constant, put it on your diagram, right-click and choose Representation, then choose U32.  You'll see that the red Coercion dot on your Enqueue function disappears.

Let us know the results of these tests, and if they help find the problem.

BS