Measuring RMS of AC signal (2 loop delay in getting actual values)

[Jim_Bach]

I have a data collection VI that is measuring, amongst other things:

NI-9225:

            240VAC voltage to a heating element

            AC current of heating element (clamp-on current probe)

The reading of these (and my other) signals are contained within a 200ms Timed Loop.

The other signals are all on-demand, 1-value reads, while the above signals are read as continuously-sampled (@ 3kHz) blocks of 100 samples (to acquire 1/30th of a second, or, 2 cycles of the AC waveform).  I pass the 100 sample block of data to the LV block that calculates RMS, and then use those RMS values to calculate power.

The problem I'm having is that I'm seeing a 2-loop delay in these block-read AC signals.  In iteration#0 I turn-on a SSR to a heating element (which these signals are measuring) using a digital output port on a USB-6211 . . . FWIW, I wired that port (driving the SSR) into an analog input of the 6211 to verify the state/level to make sure it would adequately drive the SSR.  I can clearly see that the signal goes Hi in iteration #1, but, I don't see any non-zero voltages/currents until iteration #3 . . . the Volts/Amps in iterations #1 and #2 are near-zero (noise), but snap sharply to 243V and 11A in iteration #3 (and beyond).

At first I'd thought it was just a sequencing issue, since you can't be sure of the order of execution of the blocks within a Timed Loop, so, I broke-up my code into sequenced frames . . . so that the writing to the SSR control port happened in the 1st frame, and the reading of the AC signals happened in the 2nd frame.  I would have expected to see correct AC readings in iteration#2, since it happens 200ms (i.e. 1/5th of a second) after iteration#1, and 1/30th of a second is only 33.3ms.  But, there is an extra loop's worth of delay I can't account for.

Any suggestions for thos Rookie LabView user?

Thanx (in advance)

[margasan]

Hello Jim,

Can you post the VI or at least an screenshot?? It will be my pleasure to take a look at it.

Regards

Mart G

[Jim_Bach]

The main VI and 2 sub-VIs I'd created are attached in a ZIP file.

For this VI I have 3 modules in a 4-slot C-DAQ chassis . . .

9225    AC Voltage & AC Current (clamp-on current probe)

9219    TCs in high-voltage environment

9213    TCs in safe environment

And I also have a USB-6211, using 1 digital port to control a solid-state relay (to control a heating element) and another digital port to beep a piezo buzzer when the test starts/stops.

For the AC signals I'm capturing 105 samples at 3kHz to get 100 samples over a 2-cycle period of the AC line (seems their 3kHz isn't really 3.000kHz!) . . . then using an RMS block to calculate the RMS voltage and current, which I then multiply to get power.  The voltage, current, and power values, logged into my file, seem to lag the activation of the SSR by 2 loops . . . even though I'd set-up a framed sequence to force the digital outputs on first, then take the samples.  I'd expect, at most, a 1-loop delay since 105 samples need to be collected, and I'm not sure how quickly frame#2 start after frame#1 completes.

I had started-out using DAQ Assistant blocks to do my control/read . . . but found them far too slow to let me do a 5Hz loop . . . so, learned how to use the DAQmx blocks . . . but, that didn't seem to fix the delay issue.

I appreciate you taking the time to look at this . . .

[margasan]

Hey Jim,

I took a look at your code and it i see no reason for this delay you are seeing, have try a highlighted execution??

Regards

Mart G

[Jim_Bach]

My local NI tech support person was here today, and spend some time working-out my glitches . . . seems to be working OK now.

Issues we'd discovered . . .

I was using "Continuous" sampling when I should have been using "N Samples" . . . thus what I was reading from the buffer was old data and getting older by the minute, or at least not guaranteed to be the "latest" set of samples.

I was using a "Start" DAQmx block, which needed to change to a "DAQ Control Task" block with the "Action" port wired to a "Commit" enum, to cause the N samples to be taken "on demand" when the "Read" block executed.

I seem to be up-and-running now without the strange delay . . .

Thanx for taking a look at this for me.