Do I have to dequeue each element separately?

[labview12110]

The sample clock rate (1kHz) tells the DAQ device how many samples to acquire. It determines the time between successive samples and sets an upper limit on the bandwidth of the signal being measured.

So 1kHz would be collect data every ms?

The number of samples per channel (100) tells the Read VI how much data to grab from the DAQ device.

at each millisecond read 100 samples, if there are 100 available, if not wait until there are? SInce I have it set to read continuous samples I should always have 100 samples to read yes?

With those settings you need to call Read 10 times per second to get all the data.

How do I set read to a value per second? Is that not set by the samples per channel value?

If you call it faster, it will just wait until 100 samples are available. If you call it less often, say one time per second, eventually a buffer somewhere will overflow and you will start losing data and getting errors

As for the graphs:

If this is true then why does my graph plotting rate change dramatically when I alter the samples per channel value? is the while loop iteration rate controlled by this samples per channel as well?

Sorry for all the questions, and thank you so much for all the help.

[johnsold]

So 1kHz would be collect data every ms?

---

Yes. The hardware data acquisition device will operate at that rate. The data is stored in a buffer on the device until the software reads it.

---

at each millisecond read 100 samples, if there are 100 available, if not wait until there are? SInce I have it set to read continuous samples I should always have 100 samples to read yes?

---

Not quite. Each millisecond the hardware acquires one sample. When you tell the DAQmx Read.vi to read 100 samples, it will read the 100 oldest samples in the buffer, if that many are there, or wait until 100 samples have been acquired. If you call Read as soon as the acquisition starts, it will wait 100 ms because the hardware takes that long to acquire 100 samples. 

If everything in the loop takes only a few milliseconds to run, then the loop will wait up to 100 ms on each iteration. But consider the case where something else in the loop takes 500 ms to complete. Now the DAQ device has acquired 400 more samples. On the next iteration Read will return immediately with 100 samples, leaving 300 in the buffer. Eventually in this situation the buffer will overflow and data will be lost.

Continuous samples tells the DAQ device to acquire data continuously. With the 1 kHz sample rate it will get a new sample every millisecond. It does not care whether the data is read from the buffer or not. It just keeps acquiring.

To get one reading per second set the samples to read = to the sample rate. For rate = 1000 read 1000 samples at a time.

---

 ... why does my graph plotting rate change dramatically when I alter the samples per channel value? is the while loop iteration rate controlled by this samples per channel as well?

---

The graph plotting rate is essentially the loop rate. As described above the loop rate is controlled by the ratio of samples to read to the sample rate.

This can be quite confusing until you get your thinking organized around these similar sounding terms.

Lynn

[labview12110]

I convereted everythign to a waveform but I am still not getting the time or events to write the same amount of data. For some reason I am not getting a time stamp with every data point, all changing the waveform did was add the start time to my data summary sheet.

[labview12110]

I think I figured it out! I am taking a component of one input and running that array through the ger waveform time array function. Gets me a time stamp at each data point.

Im doing this in the consumer loop though. Is it more efficient to run this prequeue and then pass the output to my tdms write?

[JÞB]

Yeah, You need a time channel

[dacad]

---

@johnsold wrote:

Continuous samples tells the DAQ device to acquire data continuously. With the 1 kHz sample rate it will get a new sample every millisecond. It does not care whether the data is read from the buffer or not. It just keeps acquiring.

To get one reading per second set the samples to read = to the sample rate. For rate = 1000 read 1000 samples at a time.

Lynn

---

The second statement would assume that the samples are brought in and averaged into a single reading.  If someone is using the individual sample values, that statement does not apply.

Only noting this because I intially misread it and thought you were saying if sample rate = samples to read,  then you would get one value.

[johnsold]

Doug,

Thank you for the clarification. One reading means one call toe DAQmx Read.vi and will return n samples to read samples in the format selected.

With the sample rate and the number of samples to read set to equal numeric values (such as 1000 S/s and 1000 samples to read) each iteration of a loop with DAQmx Read.vi (and nothing else which takes much time) will take 1 second and will return the spefied number of samples per channel (1000 in this case).

Lynn

[labview12110]

Is there a reason why elements in my producer loop would be out of sync with those in my consumer loop? Basically when I check the data file for my event numbers that column has only 1/10 of the data entries than the others, and everything is shifted up by the same amount (so the timestamp in the column does not match the waveform timestamp). How can I speed up the reporting from the event marker button?

[johnsold]

1. The event number only changes when the Record Event button is pressed, so you should  get duplicate numbers. I do not think that is what you are describing.

2. In the false case (Record Event = False) you enqueue an empty string to the Description field.  That gets converted to an empty array  in the consumer loop.

3. I do not know what TDMS Write does with an empty array but that is the first place I would look. Create a small test VI which writes known values to one channel and an alternating filled and empty array to a second channel. Then check the file to see if something similar to what you are seeing happens.

4. The Enqueue probably sends the empty string. If it did not send anything, the Dequeue would wait forever for something to arrive, freezing the consumer.

Lynn

[labview12110]

---

@johnsold wrote:

1. The event number only changes when the Record Event button is pressed, so you should  get duplicate numbers. I do not think that is what you are describing.

Yes this is intentional

2. In the false case (Record Event = False) you enqueue an empty string to the Description field.  That gets converted to an empty array  in the consumer loop.

Which puts nothign in the tdms file. Also intentional

3. I do not know what TDMS Write does with an empty array but that is the first place I would look. Create a small test VI which writes known values to one channel and an alternating filled and empty array to a second channel. Then check the file to see if something similar to what you are seeing happens.

I think that all it does it write nothing to the entry. At least in the file when I open it in excel I get the event description and then blank cells until I have hit it again.

4. The Enqueue probably sends the empty string. If it did not send anything, the Dequeue would wait forever for something to arrive, freezing the consumer.

I agree and don't think this is happening.

I am getting 1/10 the data entries from event number than i do from the actual data. I think that this is due to the loop rate, since it is bound by the loop timing. It is like what was happening with the time stamps before I moved to waveform data, i was only getting them to write to the queue 1/10 of the time as the data rate. Any idea how to change this ?

Lynn

---