multi counter PCI 6602 daqmx semi period measurement

[marconi 2042]

Hi Chris,

 

Here is the specification sheet for my sensor. The frequency is 200 Hz for both output and it is continuously producing a PWM signal.

 

Thanks,

 

Johnny

[Jordan F]

Hi Johnny

Have you tried increasing the frequency before 5 minutes to see if you have them both update at the same rate?  Also, have you tried just reading in one PWM signal (the one that is lagging) to see if it is responsive.  You could test this PWM output with the Meas Buffered Semi-Period-Continuous.vi example in the NI Example finder to see if you see the same results. 

[marconi 2042]

Hi Jordan, Thanks for your helps. I did try increasing frequency. But it doesn’t work. I also tested the lagging PWM signal with semi-period-continuous.vi example, it works fine for that signal. It doesn’t have any problem for reading 1 input signal. It only has problem by reading multi channels. Thanks, Johnny

[Jordan F]

Have you tried switching the two signal counter inputs (counter 1 signal to counter 0) to see if the problem follows with the signal?  This way we could determine if the problem lies within your code instead of the hardware.  Could you post an updated version of the code?  Maybe I could see if there is anything that stands out that might be causing this delay.  

[marconi 2042]

Hi Jordan,

 

I connected one output to counter 0 and counter 1. I run the code. It doesn’t have delay problem. If I connect output 1 to counter 0 and output 2 to counter 1, it will cause any delay problem. I checked both output frequencies. One is 194.55 Hz and other one is 194.26 Hz. I realized that frequencies are slight different, it will cause one of inputs reading delay problem if I run it long time. Do you have any ideal why it causes delay problem if frequencies are different? I also attached my updated code.

 

Thanks,

 

Johnny

[Chris_W.]

Hi Johnny,

I have read your correspondence with Jordan and I have a couple of thoughts I thought I'd share. As far as your code, I think it looks very good. Nice and clean. The only thing about the code that I can see might be affecting anything is that you do have that for loop inside the while loop. I wonder if this is creating any problems by delaying the read of one of the tasks. I would try to split your task and run two parallel tasks instead of stacking them with the for loop. The other thing that I figured you could try is to read two pulse trains that are a lot farther apart in frequency, and see if it has anything to do with the fact that the signals are so close in frequency.

The last thing that I was wondering was what are the exact symptoms that you are seeing when you say it has that "delay" for about 3 seconds? Does the semi-period measurement reading simply not update for 3 seconds? Or does it show 0's? 

Give this a try and let us know how it goes.

Chris W

[marconi 2042]

Hi Chris,

 As your advices, I run the code in parallel tasks instead of stacking them with the for loop. Now I don’t have the delay problem anymore. I put the indictor in each tasks to find out they are running at the same time or not. I see that Higher frequency run faster than Lower frequency. Do you have any ideal? Maybe there need improvement of my code. Would you take a look of my update code and capture of # of iteration run.

Thanks,

Johnny

[Chris_W.]

Hi Johnny,

I took a look at your code and I see what you are referring to, that the number of iterations of each of your tasks runs a different number of times. I would say that this is expected behavior here because you are using 6 different while loops. LabVIEW has to run each of these loops in "parallel" which means that each one uses a dedicated thread in your processor so that they can run without dependence on eachother. Therefore, depending on what else is going on in your system, there is no guarantee that these loops will run at the same speed. I am assuming that the important part of your measurement is that each of your counters read the same number of samples in LabVIEW. You could just combine all of these tasks into one while loop but do not stack them in a loop. This will ensure that the number of samples you recieve for each channel each task is going to be the same by the end of your program. It is possible, however, becasue the frequencies are slightly different that the number of samples your card recieves per channel is different by the end of the run, but combining the tasks in the same while loop would give you the same number of samples in LabVIEW. 

The other thing you could do is to time your while loops and introduce a slight delay in each of the loops by using the "Wait (ms).vi" so that all of the loops are not running as fast a possible. By doing this you could introduce something like a 10ms delay for each loop and then increase the number of samples you retrieve with the DAQmx Read VI each iteration. Give that a try and see what you think.

Chris W

[marconi 2042]

Hi Chris, I combine all the tasks in one while loop. It has same delay problem. So I think I have to use different while loops for those counters. But sometime it gets error 200141 and 200140 message. Do you have any ideals? I attached the code with different tasks into one while loop for you took a look. Maybe there are something I did wrong. Thanks, 

Johnny

[Chris_W.]

Hi Johnny,

I took a look at your code and I think that maybe I'm not explaining myself properly. First of all, why are there so many more tasks? I thought you only had two signals that you were measuring? Regardless, what I meant to say on my previous post is that you could combine your two tasks for counter 0 and 1 to be in the same while loop. When you do put them into the same loop you should also add a Wait (ms).vi into that while loop with a wait time of something like 50ms and then bump up the number of samples that you acquire with each call of your DAQmx read to something like 10 or 15.

You will get those errors if you try to run that VI the way it is because you won't be able to call each of those DAQmx Read VIs fast enough to keep up with the frequency measurements. Also, because you have now 8 channels reading signals, you are going to run into some issues with data transfer since you only have 3 DMA channels on the 6602. So, those errors were likely occuring at the DAQmx read VIs in tasks 4-8. 

Aso, if you set all of your tasks to perform interrupt transfers then you are definitely going to have some issues with timing. Is there a certain reason that you need to read all of the data at the exact same time? What you could do is just to run them all in separate loops the way you had them and then once you've stopped the VI, which stops execution of each of the while loops, you could perform another DAQmx read with the number of samples to read set to -1. If you include this VI in your task before you clear the task, then you would essentially be clearing the buffer and making sure that you are not missing any samples due to the loop iterations not ending up the same. 

I've attached an image of the way I was thinking the VI would look originally with just two tasks. I hope this helps.

Chris