multi counter PCI 6602 daqmx semi period measurement

[marconi 2042]

Hi All, Currently I am working on 20 PWM input channels. I have some problem on my labview code. Would some one give some advice on my vi? I crated labview code for 2 channels for now. I am doing semi period measurement. I want to measure the frequency and duty cycle of the PWM signals. But when I run it, it has error. Please give some advice where I did wrong on my vi. thanks Johnny

[Chris_W. · Accepted solution]

Hi marconi,

This error that you are getting is a buffer overflow error and is likely due to the value that you used as an input to "number of samples" on the DAQmx Read VI. You had it set to 4 but depending on how fast the PWM that you are reading is, you may be acquiring values to the onboard buffer much faster than you are retrieving them with the DAQmx Read VI. Then when you call the DAQmx Read VI, which reads relative to a read pointer the data that you are expecting to read from the buffer has already been overwritten. One way to get around this is to increase the number of samples to read each time you call the DAQmx Read VI. I tried out your VI and got it to work with a slight modification to the start trigger (using PFI0 instead of the 20MHz timebase) and added a loop condition to stop from getting a buffer underflow error as well. Take a look and see if this helps out. Also, why are you triggering off the 20MHz timebase? is there a particular reason? This is essentially like using no start trigger since you should get the first rising edge of that almost immediately after the DAQmx Start VI is called. I am just curious, since using this start trigger did not actually work for me (though I didn't look into why). 

Chris W

[marconi 2042]

Hi Chris,

 

Thanks for your help. I can’t open your vi because I am using labview 7.0. Can you convert it to 7.0 for me please? The reason I was use 20 MHz timebase, I didn’t create a digital signal for triggering. You said that you are using PFI0 instead of the 20 MHz timebase, Do I need to connect any digital signal to PFI0?

 

Thanks again,

 

Johnny

[Chris_W.]

Hi Johnny,

I'm sorry about that, I didn't realize it was in LabVIEW 7.0. Unfortunately I don't have 7.0 on my computer and I can't save back to 7.0 because it is backward compatible for saving from 8.0 or 8.2. However, I took a screenshot of the changes that I made to the block diagram and attached them. Also, about the PFI0 thing. You don't have to use that to trigger your start. I did just so I could control it a little more easily. You can trigger the measurement on whatever you want. Personally I would just trigger the start on a rising edge of the signal you are measuring. Doing this ensures that your measurements start on a rising edge, so you know that every 2 semi-period measurements is a period of high then low. This is just my preferrence. The only reason I asked is because using the 20MHz timebase for a trigger is almost like not using a start trigger at all. In fact it will just delay the start of the acquisition likely one period of the 20MHz timebase from when the acquisition would start if no trigger were configured. I hope this helps.

Chris W

Message Edited by Chris W. on 02-12-2009 11:01 AM

[marconi 2042]

Hi Chris,

I still get same error even I set my number of samples at 4. I trigger one of measuring signal. My frequencies are 100 Hz and 1k Hz.

Thanks,

Johnny

[Chris_W.]

Hi Johnny,

I'm sorry it's be a couple days, but I was just looking at your error code image and I realized that you are using continuous sampling. For some reason I thought you were using finite sampling. The way to fix the error you are getting is just to set the number of samples input to the DAQmx read VI to -1 which will retrieve all available samples each iteration of the while loop. Since you are continuously sampling what was happening is that you would only retrieve 4 samples per iteration of your while loop, which means that every 100ms you would retrieve 4 samples per counter buffer. Also, since you are doing a semi-period measurement, you are actually saving 2 counts to the buffer every period of your signal. This means that unless your signal is a really low freqency you will likely be writing to the buffer much faster than 40 samples per second (4 samples per 100ms). See if this works out. 

Chris W

[marconi 2042]

Hi Chris,

 

Thanks for your help. Now I don’t get error anymore. But one of counter has delay time for reading PWM signal. For the first 10 min both counters are reading ok. But after 10 mins, I can see one of counters has delay time. The longer time I run the code, the longer delay time for one of counters. Do you know why?

 

Johnny

[Chris_W.]

What do you mean it has delay time? Delay in what? There may be the case where the number of periods available to read in a given iteration of your while loop is different between channels since the two signals are different frequencies. Is this what you are talking about? If so, then that is something you would expect to see, but it could take a while for those readings to creep away from eachother if the frequencies of the two signals are relatively close.

Chris W

[marconi 2042]

Hi Chris,

 

Let me clarified what I mean delay time. I have one steering sensor. It has two output PWM sensor. Both outputs have same frequency.  But it has different duty cycle. When I run the code and turning the sensor, I can see both counter reading at same time for first 5 minutes. After running the code for 5 minutes, I spin my sensor a litter bit. I can see counter 1 reading instantly. But counter 0 delays for 3 second then doing reading.

 

Johnny

[Chris_W.]

Hi Johnny,

Are you sure that your sensor is outputting what you think it is at this point? If there is some way you could verify this, atleast with relatively high resolution it might help just to make sure. Also, What is the duty cycle of both of these signals? and what are the frequencies? Also, are they continuously producing a PWM of that frequency and duty cycle? If the time of a full period is somehow extremely long, there is a potential for the counter to roll over and create some problems. If your frequencies are relatively slow, you could change the counter timebase with a DAQmx Channel property node using the Counter Input::General Properties::Counter Timebase::Source.

Could you post a link to the specifications sheet for your sensor? That might help to expose the issue. 

Chris W