Averaging, Displaying, and Resetting Alternating Waveform RMS Arrays

[curiositas]

I'd like to sample 2 external waveforms sequentially, determined by the value of an external square wave. I'd like to take an average of an array of RMS values from these samples at the beginning of a new cycle of the square wave and reset these arrays for a fresh cycle. I'm currently having difficulties with obtaining (and thus, displaying) these mean values.

The way that I have designed this while loop is as follows (each iteration):

1. Sample waveforms and obtain digital (Boolean) value from square wave.
2. ("Array Selector Case") If the Boolean value is True (HIGH square wave), take the RMS of the waveform sampled from Source 1 and add this value to an (initially/cyclically) empty array (initialized at runtime), feeding Source 2's RMS array straight through the structure so that it is not altered; if the Boolean value is False, do the same for Source 2 without altering Source 1's RMS array.
3. ("Cycle End Case") At the beginning of each iteration of the While Loop check to see if the Boolean is True and the previous iteration's Boolean was false (indicating a new cycle of the square wave has begun).
   1. If this check is True, take the mean value of both RMS arrays and output to the charts/indicators, and reinitialize both RMS arrays to empty arrays.
   2. If False, pass the previous values (initialized to 0 at runtime) out to the charts/indicators.
4. Lather, rinse, repeat.

I am experiencing a problem in which all of my RMS (mean) values come up as NaN (as observed on the indicators), and therefore nothing is displayed on the Waveform Chart (named "rms chart"). I have attached an image of my front panel running, since I know that others will most likely not have the equipment to test this VI.

Trying to step through the iteration hasn't helped me, as an error arises when trying to read the analog inputs (presumably because of the step through). But I have been able to determine that all of the indicators and chart display 0 values during the first iteration, as intended.

I am using a function generator to generate two 10kHz sine waves (one at 5 Vpp and the other at 3 Vpp, for difference) and a single 50 Hz square wave (5 Vpp). I'm sampling the sine waves with a NI 9232 BNC module, and the square wave with a NI 9923 terminal block module. Using a separate VI to sample and display the inputs appears to work fine.

As I said, I know that it would be difficult to find others who can run this VI because of the DAQ modules, but I was hoping that somebody might be able to find a glaring issue with the logic or with the diagram that might be causing this issue. Or perhaps, this cannot be performed with these modules? I'm fairly new to LabVIEW, so any pointers (even on cleanliness, etc.) are greatly appreciated!

[GerdW · Accepted solution]

Hi curiositas,

---

@curiositas wrote:

I am experiencing a problem in which all of my RMS (mean) values come up as NaN (as observed on the indicators), and therefore nothing is displayed on the Waveform Chart (named "rms chart").

---

Set a fixed number of samples to read at your DAQmxRead calls to always have more than one sample in your waveforms!

Even collecting a single NaN in your arrays will give a NaN result for any following calculation with these arrays…

[curiositas]

---

@GerdW wrote:

Hi curiositas,

---

@curiositas wrote:

I am experiencing a problem in which all of my RMS (mean) values come up as NaN (as observed on the indicators), and therefore nothing is displayed on the Waveform Chart (named "rms chart").

---

Set a fixed number of samples to read at your DAQmxRead calls to always have more than one sample in your waveforms!

Even collecting a single NaN in your arrays will give a NaN result for any following calculation with these arrays…

---

That seems to have been the problem! I connected the control that allows the user to define the number of the samples for the Sample Clock of the analog input task to the "number of samples per channel" terminal of the DAQmx Read VI in the While Loop, and now I am getting good values out to the indicators and chart. I'm assuming that the problem was that there were iterations of the While Loop in which only a single sample (or none!) were being read by the VI which was causing the issue as GerdW suggested in his response. Thank you very much!

Now, I'm just have to figure out the reason my application can't keep up with the hardware acquisition! 🙂

[GerdW]

Hi curiositas,

---

@curiositas wrote:
Now, I'm just have to figure out the reason my application can't keep up with the hardware acquisition! 🙂

---

Maybe you don't read anough samples per iteration?

Mind to share your current state of the VI?

Btw. did you read the help for DAQmxTiming and the meaning of its "num of samples" input for "continuous sampling mode"?

[curiositas]

I have been investigating this issue, and my searches do seem to suggest that there is some issue with the difference between my sample rate(s) and my read rate.

I've followed the error to this page and implemented the "while loop benchmarking" technique so that I can try to determine my read rate.

I have read the help documentation about the DAQmx Timing VI and several other pages about it, but it is a subject that still seems to elude me. I can't seem to wrap my head around what is happening in the machine and the relationship between sample rate and the number of samples, and what the application is actually doing. I'm working on it, but I've also never studied signal theory, so I'm definitely behind the curve.

I've attached my current state VI, complete with the while loop benchmarking technique, and I've also included a screenshot of my latest front panel run (after the error occurred and I cleared it), so that you can see it's state.

Thank you for the further help! 🙂

[GerdW]

Hi curiositas,

---

@curiositas wrote:

I have been investigating this issue, and my searches do seem to suggest that there is some issue with the difference between my sample rate(s) and my read rate.

---

The "reasonable" suggestion is to set "number of samples to read" to samplerate/10.

(For usual acquisitions this should work in most cases… 😄)

Both tasks should use the same samplerate and read the same number of samples in your loop. As even then they still might diverge you should place them each into their own loops.

[curiositas]

I wondered if both sample rates should be the same, but I found that curious since the other lower Read VI is only sampling a 50 Hz square wave, so I assumed that it needed a sample rate of perhaps 100 Hz. However, changing only the sample rate for the square wave to 100 Hz did not work. I have attached a screenshot of my front panel running well while sampling the square wave at 51 Hz, but I'm not sure how long it will run... will it eventually throw and error? UPDATE: This did eventually error out, so I will need to continue to investigate placing each Read VI into its own loop, like GerdW suggests.

---

@GerdW wrote:

Hi curiositas,

---

@curiositas wrote:

I have been investigating this issue, and my searches do seem to suggest that there is some issue with the difference between my sample rate(s) and my read rate.

---

The "reasonable" suggestion is to set "number of samples to read" to samplerate/10.

(For usual acquisitions this should work in most cases… 😄)

Both tasks should use the same samplerate and read the same number of samples in your loop. As even then they still might diverge you should place them each into their own loops.

---

I will try to play around with the (# of samples = sample rate / 10) and see what I results come up with. I will also work on making each Read VI sample at the same rate.

However, could you explain what you mean about putting each one into their own loop? In their own While Loop? For Loop? I'm not familiar with putting the Read VIs into their own loops, and I'm quite new to LabVIEW, so I'm not sure how to go about doing that.

Thanks again!

[Kevin_Price]

Since you're pretty new to this stuff, let me identify that you're at a little fork in the road.  There's more than one way to proceed, and you may prefer one path to the other at this particular time.  Here are 2 general options:

1.  Work on learning how to have separate loops for your Analog and Digital Reads.  You'll need to learn some new software architecture lessons such as dealing with parallel operations, moving data from one loop to another, and shutdown procedures that work across multiple parallel loops.

2. Work on learning more of the inner workings of DAQmx-based data acquisition.   There's quite a bit of flexibility with DAQmx, including ways to manage both Analog and Digital in a single shared loop.

It's not a totally clean-cut decision and some of the new stuff down each path will matter even if you mainly take the other one.  But if one set of learning sounds much more appealing than the other (even if just for now), it'll help us to focus on an approach.

Sorry, don't have time to write up a long tutorial on either path, just hoping to steer the conversation in a direction that you'll find most helpful.

-Kevin P

[curiositas]

---

@Kevin_Price wrote:

Since you're pretty new to this stuff, let me identify that you're at a little fork in the road.  There's more than one way to proceed, and you may prefer one path to the other at this particular time.  Here are 2 general options:

1.  Work on learning how to have separate loops for your Analog and Digital Reads.  You'll need to learn some new software architecture lessons such as dealing with parallel operations, moving data from one loop to another, and shutdown procedures that work across multiple parallel loops.

2. Work on learning more of the inner workings of DAQmx-based data acquisition.   There's quite a bit of flexibility with DAQmx, including ways to manage both Analog and Digital in a single shared loop.

It's not a totally clean-cut decision and some of the new stuff down each path will matter even if you mainly take the other one.  But if one set of learning sounds much more appealing than the other (even if just for now), it'll help us to focus on an approach.

Sorry, don't have time to write up a long tutorial on either path, just hoping to steer the conversation in a direction that you'll find most helpful.

-Kevin P

---

That's fantastic, and I very much appreciate the solid insight there. It definitely helps me see the fork in the road and gives me a direction to head in, which often what us newbies need!

Since it sounds like separating the analog and digital reads into their own loops is the most suggested way to read both, I suppose I'd have to say that I'd want to travel down track #1. I'll start reading up on those subjects and see if I can glean any insights from that.

Thank you so much, again!