Invalid values in buffered period measurement read buffer

[Mroche]

In the NI documentation for "Configuring a Time Measurement in NI-DAQmx"  it states "depending on the phase of the input signal in relation to the start of the measurement, the first sample of buffered measurements is often invalid." This is exactly what I'm seeing. There is good data in the buffer, just with invalid data points on either side.

Is there a way for the values in the buffer to only be full period measurements?

I have tried setting up an Arm Start trigger on the gate signal of the channel hoping that when I would start the task, the actual counting would not start until the gate signal (the same signal that identifies the beginning of a period) was detected by the card so that only valid period measurements would be in the buffer. But that didn't work; with or without the trigger, it performed the same.

Is there a way I can arm the counter to start counting at the first active edge of the gate signal?

Thank in advance.

"

[GarPar]

Hi Mroche-

     What counter input measurement type are you performing?  With measurements coming in on the gate of the counter, you are going to need to throw out your first sample as that may have come in mid-period.  The Arm start trigger should function like a traditional AI start trigger, so for something like Edge Counting, Arm Start Trigger will set your counter to zero and start counting.

     If you throw out your first data point, your data should be fine.  How have you setup your program?

[Mroche]

I have the counter setup as a buffered period measurement and yes I have the program written (C++).

Throwing out the first measurement in the buffer isn't the best practice as this is in an automated testing environment and I need to be sure that whichever measurement I return is valid (or invalid if the unit testing is defective). I'd rather have the buffer only contain full period measurements.

Is there anyway to hold off the starting of the counter until the first active edge of the gate signal? That way all measurements in the buffer would be valid.

What does the triggering do? I figured the trigger would work like an oscilloscope and the counter would not start counting until the trigger (the gate signal in this case) was seen.

[JustinP]

Hello,

I am attaching a link that describes an example that synchronizes two counters with an arm start trigger.  The example is written in LabVIEW so I am attaching a screenshot that reveals the code with the steps described.  Basically this approach can be used to synchronize the counter with the incoming signal.  This should ensure that the first sample is a full period depending on the rate at which you are acquiring the signal. 

http://zone.ni.com/devzone/cda/epd/p/id/6081

Regards,

Justin

[Mroche]

My application is written in C++ and I'm have a difficult time understanding the LabView example.

Could you either provide a C example or explain the steps in psuedocode?

I do not understand what the analog input channel is suppose to do and how that uses the trigger.

[GarPar]

Hi Mroche-

     The steps to perform the measurement are outlined below:

1. Create a Counter Input channel.
2.  Call the DAQmx Timing function (Sample Clock) to configure the external sample clock timing parameters such as Sample Mode and Sample Clock Source.  The Sample Clock Source determines when a sample will be inserted into the buffer.  The 100kHz, 20MHz, and 80MHz timebases cannot be used as the Sample Clock Source.  The Edge parameter can be used to determine when a sample is taken.
3. Use the DAQmx Trigger property node to configure a Digital Edge Arm Start Trigger. The Trigger Edge determines if a rising or falling edge will start the counter.  The Trigger Source determines the location of the Arm Start Trigger.  There is a great discussion forum post that has the exact syntax for an arm start trigger found here.
4.  Call the Start function to arm the counter.  The counter will begin counting edges when the Arm Start Trigger occurs.
5.  Writes a signal to Port1/line0 which is routed to PFI0. PFI0 is being monitored by the ArmStart Trigger from Step 3. This begins the acquisition for the two counter tasks.
6. For continuous measurements, the counter will continually read all available data until the Stop button is pressed on the front panel.
7.  Call the Clear Task function to clear the Task.
8.  Use the popup dialog box to display an error if any.

These are the basic steps of the program.  The dummy analog input is basically an analog input task that is created but the data is not being read or used. This is done because you can use the aiSampleClock of this analog input to synchronize the two counter tasks.  In your case, the aiSampleClock will not be used.  In this example, it is used as the single timebase for both counter tasks so that they are synchronized.  You can ignore that task for now.

Another great thing to look at is the text-based code support we already have for DAQ.  Click on Start»Programs»National Instruments»NI-DAQ»Text-based code support»Visual C++ examples folder.  In the Text-Based Code Support folder, you can also select the NI-DAQmx C Reference Help document for more granular explanations of what each function does.

I hope this helps.  Have a great day!

[Mroche]

I have implemented the Arm Start trigger into the channel setup, but am still seeing invalid values in the buffer although it changed slightly. Before without the trigger the buffer, most of the time, looked like [0], [invalid], [valid], [invalid]. Adding the trigger caused the first sample, [0] to not be in the buffer. It now looks like [invalid], [valid], [invalid]. Occasionally, only two sample were read with the buffer being [valid], [invalid].

I need the counter hardware to consistently only put valid values in the buffer. I have six counters to measure the output of three gyros. The following code is in a loop to setup all six counters as separate tasks. Each task is essentially the same except the correct PFI numbers will be entered for the respective counter. Also three of the channels will be setup with IRQ for the data transfer mechanism since the PXI-6602 only has three DMA channels.

// Create task

DAQmxCreateTask(taskName, TaskHandle);

// Create period channel

DAQmxCreateCIPeriodChan(TaskHandle, ctrName, "", 0.000001, 0.1, DAQmx_Val_Ticks, DAQmx_Val_Falling, DAQmx_Val_LowFreq1Ctr, 0.000001, 4, "");

// This will be set to the PFI of the gate for the counter        

DAQmxSetCIPeriodTerm(TaskHandle, "", "/CTR1/PFI38" );

// Set the Timebase Source to the Counter's source PFI (ex. /CTR1/PFIXX)

DAQmxSetCICtrTimebaseSrc(TaskHandle, "", "/CTR1/PFI39");

DAQmxSetCIDataXferMech(TaskHandle, "", DAQmx_Val_DMA );

DAQmxCfgImplicitTiming(TaskHandle, DAQmx_Val_ContSamps, 1000 );

// Setup the Arm Start Trigger to trigger on 1/rev pulse

DAQmxSetTrigAttribute (TaskHandle, DAQmx_ArmStartTrig_Type, DAQmx_Val_DigEdge);

DAQmxSetTrigAttribute (TaskHandle, DAQmx_DigEdge_ArmStartTrig_Src, "/CTR1/PFI38");

DAQmxSetTrigAttribute (TaskHandle, DAQmx_DigEdge_ArmStartTrig_Edge, DAQmx_Val_Falling);

I need to measure pulses coming from gyros for one revolution of a spinning rate table. The rate table outputs a pulse once per revolution and that is wired into the gate of the counters. I don’t know where in the revolution, which is the period I’m trying to measure, the counter task will start. So, what I’d like to is to trigger the counters to start on the 1/rev pulse from the table. That way the counters will not start counting until the next period. Therefore, only good values will be in the buffer when I read it. How do I do that?

I have looked at the sample code provided and have extensively search the forums and NI developer zone, but still have not found what I’m looking for. It seems that the above code should do what I want. What am I missing?

[Kevin_Price]

I've got a few thoughts, hopefully at least one of them proves relevant & useful.

1. Do you have a timebase clock signal wired to the counters' source pins (shown as PFI39 in the example code below)?  By specifying PFI39 as the timebase source, the count value will only increment on active edges at PFI39.  I wonder if you ought to use the internal timebase instead?

2. There's a property with a name like "Duplicate Count Prevention."  I don't know the exact syntax in C, but you might need to look into this property, especially if you sometimes get 0 active edges from the timebase (PFI39) between consecutive active edges at the period terminal (PFI38).  This is especially likely to be part of your troubles if indeed you aren't supplying a clock signal at PFI39.

   If you get "invalid" data for any sample other than sample #0, then you most likely have either an issue with this "Duplicate Count Prevention" property, or you have noise spikes that register as edges.

3. Many times in the past when measuring periods, I've simply tossed away the first buffered value rather than making a more complicated triggering/timing scheme just to avoid it.  I was also a little unsure about a scheme where the same edge acted as both trigger and sample clock.  I didn't feel confident predicting whether the initial edge would both trigger the task and buffer a sample or whether the first sample wouldn't be buffered until the 2nd edge.

4. I'm not familiar with the gyros you mentioned -- why is it that you need 6 counters to measure 3 gyros?

5. You may have some further options for timing and synchronization by using the 7th and 8th counters in pulse-generation modes that require neither DMA nor interrupts.

-Kevin P

[GarPar]

Hi Mroche-

     I am not sure I am following your logic with the 1/rev pulse, but it sounds like what you want is to do buffered period measurement.  If you take a look at page 7-7 of the DAQ M Series User Manual, you will see the explanation of how buffered period measurement works.  BPM essentially continuously measures the period of a signal on the gate of the counter.  The counter starts measuring the period of the gate signal after the trigger is armed, which may occur in the middle of the first period, so it is prudent to throw away the first sample.  Every sample after that will be taken on succeeding rising edges of the gate signal.

     Here is an example in C++ of buffered period measurement that you can refer to.

     Best of luck with your application!

[Mroche]

---

@Kevin Price wrote:

I've got a few thoughts, hopefully at least one of them proves relevant & useful.

1. Do you have a timebase clock signal wired to the counters' source pins (shown as PFI39 in the example code below)?  By specifying PFI39 as the timebase source, the count value will only increment on active edges at PFI39.  I wonder if you ought to use the internal timebase instead?

The gyros are wired to their respective counter source, and each counters corresponding PFI line is specified accordingly. For example for ctr0 - PFI39, ctr 1 PFI35, ctr2 PFI31, etc. I'm using the gyros as an external counter source.

2. There's a property with a name like "Duplicate Count Prevention."  I don't know the exact syntax in C, but you might need to look into this property, especially if you sometimes get 0 active edges from the timebase (PFI39) between consecutive active edges at the period terminal (PFI38).  This is especially likely to be part of your troubles if indeed you aren't supplying a clock signal at PFI39.

   If you get "invalid" data for any sample other than sample #0, then you most likely have either an issue with this "Duplicate Count Prevention" property, or you have noise spikes that register as edges.

I'll look into this further. I'll try enabling this to see what happens, and post my results.

3. Many times in the past when measuring periods, I've simply tossed away the first buffered value rather than making a more complicated triggering/timing scheme just to avoid it.  I was also a little unsure about a scheme where the same edge acted as both trigger and sample clock.  I didn't feel confident predicting whether the initial edge would both trigger the task and buffer a sample or whether the first sample wouldn't be buffered until the 2nd edge.

I've tried this, but in the case where I only receive two samples back ([valid], [invalid]) I'd be throwing the valid sample out.

4. I'm not familiar with the gyros you mentioned -- why is it that you need 6 counters to measure 3 gyros?

I need six counters because each counter has an up and down counter line. I then subtract the down counts from the up counts to get the total counts for that gyro.

5. You may have some further options for timing and synchronization by using the 7th and 8th counters in pulse-generation modes that require neither DMA nor interrupts.

-Kevin P

---