Re : Reading PWM inputs to PCI-6602 (NiDAQ-mx)

[Christ0phe]

Hello,

I am trying to simultaneously read the duty cycle and frequency values sent to the CTR0 of my 6602 PCI board. So far I am only able to read either the frequency (Create Channel: CI freq) or the Pulse Width (Create Channel: CI Pulse Width) the latter to get the duty cycle. This works. But if I try to open two create channels to the same counter it does not. How can I cascade or get the two information continuously and simultaneously? It is kind of weird that there is no function that is the symetrical of the CO Pulse Freq where I can supply the frequency and the duty cycle.

Any thoughts?
Thanks,
Christophe

[Joris_D.]

Hi Christophe,

You can't do such measurments together on the same counter. You will get the error that the specified resource is reserved.
You can only switch between measuring the freq of the signal and the pulse width.

The reason is that the counter is busy with continously measuring the frequency of the signal. And cannot start with measuring the Pulse width.
Your 6602 has got 8 counters so i guess you can just use another counter for measuring the Pulse width or is this not possible?

I have attached a simple VI which does a freq and pulse width measurement at the same time. But the 2 DAQ assistans are configured for different counters. When you want to use the same counter in both DAQ assistants Labview will give an error, you can check that.

If you have to use 1 counter for both measurements, the only option i can think of, is to measure the signal and do the freq and pulse width analysis in the software.

[Kevin_Price]

To get both from a single counter measurement, configure it to measure semi-periods.   Every pair of consecutive values will be a high time, low time pair.  Freq is just 1/(high + low) and duty cycle is high*freq, or high/(high + low).

-Kevin P.

[Christ0phe]

Thanks a lot for your answer, it does the trick. The only problem I am left with is that to get a reliable measure in the Semi Period mode, the channel must be triggered otherwise I can get the low edge first than the high edge or vice-versa. So trigger is mandatory. In my case i would like to trigger on the signal itself choosing for instance Start Digital Edge (Rising) then I am sure I get always the high edge before but if I insert the DAQmx Start Trigger icon with this setting I get the error -200452, not supported fir the device. My counter is dev3/ctr0 and the source I/O that I choose for the trigger (same as the ctr0) is hence /dev3/PFI38

Any thoughts? Is it possible to trigger on the same counter than the one I am continuously acquiring?

Thanks a lot,

Christophe

[Kevin_Price]

Two answers.  Either one alone should help -- no real need to do both.  Note: I am assuming buffered measurements.  Behavior may be slightly different for single measurements.

1. The standard digital start trigger can't be used for counter input measurements -- it's only for counter output pulses and pulse trains.  For input tasks, you need to configure an "Arm Start" trigger which is only available in LabVIEW via a DAQmx Trigger property node.

(This is a recurring point of confusion for counters under DAQmx.  I'm really not sure why NI chose to implement the API the way they did.  I've yet to see the advantage of it.  Just about any timed task except counter input can be triggered with a Digital Start trigger.  No task except counter input can use a digital Arm Start trigger.  Why they didn't just let users call it a Digital Start trigger and then do the conversion under the hood remains a mystery to me...)

2. There should be another DAQmx property node (probably a DAQmx Channel property node) that will let you define the polarity of the semi-period signal you wish to measure.  This was at least possible for 6602's under the legacy driver.  If you specify "high" or "rising" (don't recall the syntax), the very first value buffered will be the time from starting the task until the first rising edge.  (If a falling edge comes in before the first rising edge, it'll be ignored.)  The first value is meaningless for PWM.  So the array will hold:

(meaningless time, high time, low time, high time, low time, high time, low time, ...)

I'm expect that if you don't buffer the measurements, you won't get an initial meaningless value.  However, I don't think I've ever tested this.

-Kevin P.

[Christ0phe]

Kevin, Thank you for your precious explanations. The trigger actually works well, but only in the first iteration of my while loop (see WorkOnlyFirstTime.jpg) which is logical as the as soon as the next iteration start there will not be any new synchronisation. The RestartTask.jpg works well but is awfull and slow to restart the task at each iteration. So the conclusion is that I cannot find any way to guarantee the ranking of the two elements (width low, width high edge) that I get except if I restart the task at each iteration. The problem is that even if I set a wait time of 0s between my iterations in the While loop I can not be sure that I will not miss a sample. I could also use the pulse width mode which works well but does not supply both high and low edge width to allow me compute both frequency and duty cycle using only one counter... If you see a possibility please let me know I would be very grateful. Thanks a lot, Christophe

[Kevin_Price]

I'll address only the 'WorkOnlyFirstTime' screenshot since the other method has already pretty much reached its dead end. 

First, I'm not sure what you meant by:

The trigger actually works well, but only in the first iteration of my while loop (see WorkOnlyFirstTime.jpg) which is logical as the as soon as the next iteration start there will not be any new synchronisation

Your approach looks like it should continue capturing samples and displaying results until you hit your Stop button.  What exactly doesn't work on the next iteration after the first?  Do you mean an iteration of the While loop itself or do you mean another iteration of the entire test?  Or maybe you're thrown by the fact that you only see 1 iteration worth of data because each While loop iteration overwrites the old values.  If so, wire the data out to a Waveform Chart which will accumulate samples over many iterations of the While loop.  (Note: you still have some work to do to properly convert your data to freq and duty cycle).

-Kevin P.

-Kevin P.

[Christ0phe]

Kevin,

Let me try to explain better: the first iteration of the While loop will retrieve a certain odd or even number of edges. I will discard the first sample and will get the correct widths for both high and low edge. But this is only because when I enter the while loop the first time my acquisition is synchronised (trigger armed) on the first counter edge. Then I will wait 100ms (in the while loop) and read another bunch of samples. I assume that I will not miss any samples that came during the 100ms pause, is this correct? If yes then the problem will remain that I will not know if the reading of my second iteration in the while loop starts with a high or low edge, I have no means to assess that and hence I am stuck. Ideally at each iteration of the while loop I should re-arm the trigger and start task (?) but I do not think this works...

I hope this is clearer,

Thanks for your patience,
Christophe

[Kevin_Price]

Correct, the data acq task will NOT miss samples during your call to Wait 100 msec.

The good news is that you really aren't nearly as stuck as you think.  When you call DAQmx Read, you have control over the # samples to read.  As written, your code doesn't wire an explicit value so the default value of -1 is used.  This has the special meaning, "read all samples available right now."  So when you run your code, sometimes you'll get an even # of samples, sometimes an odd #.

This can throw your alignment off, but only if you let it.  There are several approaches to fix this issue, including:

1. Continue reading as you do now, but keep track of the total # of samples you've read.  Then use the odd- or even-ness of this total to decide how to interpret this loop's array of data.

2. Continue reading as you do now, but use something like a "producer - consumer" pattern to send the data off to another loop that handles the processing and bookkeeping.

3. Explicitly choose to Read only even #'s of samples during each loop, with possible exception for the first discarded value.  There's a DAQmx Read property node to query # of available samples.  Query it, round down to an even integer, then Read that even # of samples.

-Kevin P.

[Christ0phe]

Hello Kevin, Thanks for the great paths you suggested, it works perfectly well if I wire an even number of course. What I did not understand at first was that reading a defined number of samples simply discarded the excess number of samples from the buffer. In my ignorance I fell like at the next reading I would just have the old samples and the newly accumulated ones and not only the new ones. Thanks a lot for your great advises, Christophe