LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Read vi producing blank element after reading the specified number of samples per channel

Hello,

 

I'm using 6 accelerometers connected to a cDAQ-9174 with NI 9215 modules.  I'm using the DAQmx Read vi (in my producer loop) with the number of samples per channel set to 2000. When I run my program, a blank element occurs in the data output of this vi after every 2000 samples. The time stamp between the last value of the first 2000 samples, and the first value of the subsequent 2000 samples indicates no data has been skipped or lost. If I change the samples per channel, the blank element occurs after this specified value.

 

Is there a way I can prevent this blank element from occurring?

My data is sampled continuously at a rate of 1000Hz.

 

Please find my code attached.

 

Thank you in advance for your assistance,

Rach_17

0 Kudos
Message 1 of 7
(3,536 Views)

I'm assuming that you intend to sample continuously until you end the While loop.  I've always configured my Sampling Mode as "Continuous" for this situation, never "Finite Samples" -- see if this fixes your problem.

 

Bob Schor

Message 2 of 7
(3,469 Views)

Along with Bob's suggestion you have some other problems.

  1. DAQmx read is 2000 samples at 1kHz that means about 2 seconds between reads.  That is as fast as you enqueue data.  Your Dequeue has a 200mS timeout so you will get default data out and operate on it more often that you get actual data
  2. Waveforms on the consumer Shift Registers.  Perhaps you intend to add code there but, it is likely to be default data whenever real new data is present (see 1)
  3. How many times did you want to log the data?  No need to do it in the producer loop at all
  4. Exit strategy is not quite right.  When you press Stop (or get an error) you send a T Boolean then immediately destroy the notifier.  The consumer loop may not actually stop.  since you also destroy the data queue when the producer loop exits just Trap the error and exit the consumer loop.

"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 7
(3,461 Views)

Thanks for your reply Bob.

I checked this and it appears that my sampling mode is set as continuous so the problem may be elsewhere.

 

Thanks,

Rach_17

0 Kudos
Message 4 of 7
(3,446 Views)

@Rach_17 wrote:

Thanks for your reply Bob.

I checked this and it appears that my sampling mode is set as continuous so the problem may be elsewhere.

 


According to the code you posted yesterday (the relevant function is shown below), you have set your sampling mode to Finite Samples.  I do not understand why you say the sampling mode "appears" to be set as continuous.

Finite Samples.png

Bob Schor

0 Kudos
Message 5 of 7
(3,430 Views)

Apologies I didn't realise that was in the code I posted. I had updated the sample mode to continuous but was still having the same problem.

 

Thanks,

Rach_17

0 Kudos
Message 6 of 7
(3,420 Views)

Hi Jeff,

 

Thanks for your help, I'm new to labview so I've been modifying a previously written code.

 

 In relation to each of the points you've raised:

1. Would I need to set my dequeue timeout higher than the expected time it will take to enqueue the data. I.e. for the example of 2000 samples at 1kHz, would my dequeue timeout need to be greater than 2 seconds to ensure I won't be operating on default data?

 

2. I'm not sure I need the shift registers now that I've changed my code. For future reference would it be best to connect the data component of the waveforms to the shift registers?

 

3. The logging in the producer loop was just a hangover from some testing, I've since removed it from my code.

 

4. I've modified my code based on the solution I found in the link below, hopefully this will fix the problem.

https://forums.ni.com/t5/Example-Program-Drafts/Producer-Constumer-Events-With-No-Data-Loss/ta-p/352...

 

Thanks again,

Rach_17

 

 

 

 

0 Kudos
Message 7 of 7
(3,418 Views)