Simultaneous pulse width and period measurement

[ace-eng]

So far, I have two separate measurements for pulse width and period using the PXI6602 counter/timer. I'd like to combine the measurements into one step. Is there a method using the internal clock as the source and the unknown signal as the gate in order to obtain simultaneously:

1. Number of edges of source for rise to fall of gate signal (e.g. pulse width)
2. Number of edges of source for rise to next rise of gate signal (e.g. period)

Thanks.

[gus]

If you can do some post-processing, you can use semi-period measurement. This measurement returns separate values for the high and low pulse widths of a given signal. By summing up pairs of measurements, you can get the period for the signal. Every other measurement, will be the pulse width measurements. There is one catch though, currently there is a known issue with DAQ 7.3 where the starting edge cannot be determined. A workaround for this is to use the arm start trigger functionality of the TIO to begin on a rising or falling edge. There is an example that is very simliar to what you want to do that ships with NI-DAQ 7.3 called "Meas Duty Cycle-Buffered-Finite.vi" The only thing you should have to change about this example is the processing on the data from the Read VI.

I hope this helps!
gus...

[ace-eng]

Thanks for the quick reply - this is exactly what I was looking for. Is there an example of using the workaround for starting edge that you mentioned? Thanks again.

[DaytonaEd]

I'm not sure if I am clear about the following statement:

There is one catch though, currently there is a known issue with DAQ 7.3 where the starting edge cannot be determined. A workaround for this is to use the arm start trigger functionality of the TIO to begin on a rising or falling edge.

I think it affects me and I need to eliminate it if possible. When I perform a low-frequency measurement (using the signal as the gate), the first measurement is always wrong I assume because it starts measuring immediately on start task. Is this what you are implying by the starting edge cannot be determined?

If so, what command are you referring to with "arm start trigger". I cannot find this in the channel properties.

Ed

[gus]

The behavior you are seeing on the first sample of a frequency measurement is not what I am talking about here. This is specifically for semi-period measurement, where the task is measuring both high and low pulses. I believe you may be able to use the arm start trigger to elminate the first sample issue on a frequency measurement task, but I haven't verified this myself. You can configure the arm start trigger using the methods:

DAQmxSetArmStartTrigType()
DAQmxSetDigEdgeArmStartTrigSrc()
DAQmxSetDigEdgeArmStartTrigEdge()

I hope this helps!
gus....

[DaytonaEd]

OK, I have implemented the Arm Start Trigger using for now a DO connected to PFI0 and it appears to be working. This remains to be verified with more testing.

Is there a way to do this without using a hardware input (such as PFI0), in other words can the counters be "enabled" through software after both tasks are started?

Ed

[gus]

Currently there is no software start behavior for the Arm Start Trigger. On either an M Series or TIO, you can generate a pulse using a digital output line on the same line that you are using for your arm start trigger. For instance, on a TIO, you could select PFI0 as you arm start trigger source and generate a pulse on P0.0 so you did not have to make any external connections.

I hope this helps!
gus....

[DaytonaEd]

Gus, that is what I was looking for. I had tried to use "Dev2\port0\line0" in the call to
DAQmxSetDigEdgeArmStartTrigSrc but it would not take it saying that could not be routed. It had not occured to me to try using "\Dev2\PFI0" as a digital output, but that appears to work fine. Before I had routed line0 to PFI0 with a jumper that is no longer necessary. This is a PCI-6220 M-series by the way.

Ed