Error 200279 - LabVIEW Buffering Issue with Accelerometers

[dirtN3rd]

Hi,

I am very new to LabVIEW (only having learnt the program last week), and I am encountering a buffering issue that has me stumped.

I am trying to acquire acceleration signals with time measurements from three accelerometers on channels a0 -a2 using a NI 9234 Module (and a cDAQ 9174 chassis). Our goal is to determine the shear wave velocity of a shear wave passing through soil by placing the accelerometers on the soil surface, and striking a metal plate with a hammer (offset some distance from the accelerometers) to initiate the wave.

Initially, we had trouble acquiring "smooth" signals from LabVIEW (we have been viewing the acceleration vs. time plots in Octave). The data points were only logged every 3-4 ms (sometimes upwards of 8 ms)... and we could not speed up the iteration with multiple attempts at the following approaches:

- changing the sampling rate and number of samples per channel,

- using a "wait",

- trying "tick count" and "high resolution relative seconds" to get the elapsed time measurement,

• changing the sampling rate and number of samples per channel,

• using a "wait",

• trying "tick count" and "high resolution relative seconds" to get the elapsed time measurement,

• removing the waveform plots, as this is also said to bog down the while loop
• switching the DAQmx Read VI Type, to create different forms of data (i.e., double and waveform)
• use of shift register for the elapsed time
• breaking out the task into separate channels, and creating a task manually within LabVIEW (instead of through MAX)

These may not have been the right approaches (or may not have been executed well), but I have had the help of others in my college who have experience with LabVIEW to execute them. We want a smooth plot with equal sampling intervals of 1 ms or less. We are anticipating sampling rates of up to 2kHz as well. This initial code is attached as "V4...".

I created a second set of code, attached as "V12..." after watching the following youtube video: https://www.youtube.com/watch?v=fIy6XT3CdPQ

This helped us get an output of many readings for every 1 ms, which is great! It does experience larger time intervals in the first 2-2.5 s of measurements and then shows a smoother trend later on in the acquisition (please see the attached images). Our issue with this new code is that the sampling is still not at equal increments (not sure if this is even possible) and we are running into a buffering issue. I have also tried similar approaches as mentioned above to resolve this issue, but no luck. I even moved the file saving outside the loop. It was recommended I try a ring buffer, but I am not sure how to set this up.

Can someone please offer some advice on how to fix my V4 or V12 code? I have attached the text outputs for reference as well. This is currently holding up my research, so I will be grateful for any advice you can offer!

Thank you!

Chelsmar

[chelseymar97]

Following the response to this.

Chelseymar97

[testproggie]

I don't have the time right now to give you a more thorough answer, but here goes. First the NI 9234 cannot accept just any data rate. See page 15 of the manual - it is based on the clock frequency used and a couple of other items. The number of samples commonly is data rate divided by 10. 

Use waveform data instead of DBL as it has everything you need embedded within it. Also, a switch to .tdms file format would be a great improvement. Excel can open it if the addon for tdms has been installed. Or use LabVIEW to post-process the data into a format you can easily work with.

I have attached a vi that may help - although I am not sure it will run properly as it is edited from the original (which contains subvi's that I didn't want to deal with). There should be several hints in it to get you started.

[Bob_Schor]

I'm unable to open your V12 hires VI -- it seems to be a picture of a Front Panel, without a Block Diagram (so I can't see the code).  However, I could open the (much smaller!!) V4 VI, and can see (at least part of) the problem.

Here it is -- you are "very new" to LabVIEW, and don't understand its main Principle, the Principle of Data Flow.  I can't tell if you've set up the DAQmx specs correctly, but here's what I think you are setting up:

• You have 3 Channels of A/D set up.
• You are sampling at a rate of 2000 Hz, taking 4500 samples per channel.
• You are sampling using Continuous Samples.
• You failed to wire "Number of Samples per Channel" in the DAQmx Read function. 

The first three points are fine.  The omission of Samples/Channel in the DAQmx Read means (if you read the Help for DAQmx Read -- right-click the function and choose "Help") that with Continuous Samples, you'll get as many samples as are in the buffer.

Look at what you are specifying -- 4500 continuous samples at 2000 Hz.  This means that every 4500/2000 = 2.25 seconds, the DAQmx Read buffer will be full.  If you wire 4500 (by branching Samples per Channel, bringing the branch into the While Loop, and connecting it to the Number of Samples per Channel input of the DAQmx Read), then the DAQmx Read function, will work as follows:

1. When first called, it will wait 2.25 seconds for its buffer to be full.  When it is, it will "spit out" a 2D Array (because "You Asked for It") of data, while immediately continuously sampling.
2. You can do anything you want inside the loop as long as it takes < 2.25 seconds, so that you finish and can start the next loop before the next sample has been acquired.
3. When the While loop starts its next "loop", it will wait a shorter time until the second buffer gets filled.  It will then present those data, and start the next loop, over and over, until you tell it to end the loop.
4. The key step, here, is that the DAQmx Read is the "clock" for the loop.  You should have no Wait functions in here, but should let the Data Acquisition "drive" what you do in the loop.

OK, that's fine if you can process all 3 x 4500 samples in the 2.25 seconds between DAQmx Reads.  What if you can't?  What if you are doing "time-intensive" things such as plotting, or file I/O?  LabVIEW to the rescue again -- look up the Producer/Consumer Design Pattern in LabVIEW, another example of the Principle of Data Flow enabling parallel processing, with lots of things happening "pseudo-simultaneously".

For now, I'd suggest wiring Sample/Channel to the DAQmx Read, getting rid of the Timing Functions, and trying the code without file I/O.  I'd guess you'll be able to plot all three Charts, but note they'll update every 2.25 seconds (because that's how you are acquiring the data).  

See how that works.  If it's not what you want, for example, if you'd like to see plots update at, say, 20 times/sec, then all you have to do is to shorten the sampling time -- sample 100 points at 2000 Hz and every 0.05 seconds, you'll get 100 points.

Bob Schor

[chelseymar97]

Hi,

Thank you both for your help. I have connected the number of samples per channel directly to the DAQmx Read function, and am using the appropriate sample rates for the NI 9234 Module (according to the manual - thanks again!). I also got rid of the timing functions I had originally built in; though, I kept the elapsed time to record the time of measurement (this does not influence the run rate of the loop to my best knowledge).

I cannot determine how to acquire the waveform data in a useful file format without using tdms. I would love to use tdms; however, I do not have the approval for the add-in program from my employer at this time. Therefore, I am just writing to a text file. When I write to a text file using 10240 Hz sample rate, and 1024 samples per channel (1/10 the sample rate)... I get less frequent acceleration measurements than when I use a 10240 Hz sample rate and 2 samples per channel. Is there anyway I can sample more frequently such that I can develop a smooth plot of the acceleration vs. time? Please see the attachments of the front panel, and plots for reference.

Thank you,

Chelseymar97

[chelseymar97]

Thank you for your reply. Please see my additional questions in the comment below. I look forward to trying your attached vi once I have the appropriate tdms software.

Chelseymar97

[testproggie]

Have a look at the Example vi (2017 LabVIEW). This one will post-process the data from the created .tdms file to a standard .csv file.

Have a good day!

[dsb@NI]

I recommend that you try the DSA Soft Front Panel to acquire a triggered data set and save to TDMS. Then, use the code testproggie supplied to post process the data from TDMS to CSV:

[Bob_Schor]

Please attach code as .VI files, not as "pictures of block diagrams".  If I was asking you for help on a C++ program, would you like to see a picture of 5 pages of text, or have the actual program file to look at (and to edit, and to even try to run).

Bob Schor