Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Acquiring analog voltage and Freq using producer/consumer architecture

Hi

When I acquire voltage and Freq data using PCI6221, I select a producer/consumer architecture with three loops,which are events loop,daq loop and error loop,I put the analog read VI and counter read VI in the same state that in DAQ loop, but when freq sensor runs slowly or stop, the counter VI will wait data to come,which always lead the analog buffer overflow.Anyone knows what should I do if I must use producer/consumer architecture because of the complex controlling need.

 

Thanks.

0 Kudos
Message 1 of 7
(4,365 Views)

I can think of a couple alternatives for you.

 

1. Structure the code that queries the counter task to be more forgiving of this kind of expected situation.  That'll involve not waiting for a long timeout on the Read, because during that long wait the AI task gets a buffer overflow.

   You could query and store a DAQmx Read property like "Total Samples Acquired" or "Available Samples".  Comparing the present value to the former value lets you know how much data is there to read, if any.  From there you can decide whether to call the Read function or not.  Maybe it makes sense for you app to generate dummy data to report 0 frequency.

 

2.  Maybe the two different DAQ tasks can be in separate loops so they don't interfere with each other.  However, it could get tricky trying to keep their data in sync when you separate them.

 

 

-Kevin P

 

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 7
(4,361 Views)
Thans for your help,Kevin P. I tried the methord that you thought of, but troubles still exist. Firstly, I can't put the DAQmx Timing VI in the configuration before the acquiring loop, if I have done this, there would be errors after a few cycles because of data overflow. If I configure the counter in need mode, properties such as "Total Samples Acquired " or "Available Samples " are not permitted.I also tried some other methods to solve this trouble ,but all failed. I think if the counter is configured in need mode, there may be no buffer can be used , only one data in the register and every loop the read VI just read this data, if the motor stops, there will no data can be acquired and no data exists in the register,and the read VI will wait until times out. Any other method to solve it? Thanks very much.
0 Kudos
Message 3 of 7
(4,342 Views)

It'll help if you can post your code.

 

 You're right about the limitations of "need mode" (also called software-timed or on-demand).  You should plan to set up a buffered task with a call to DAQmx Timing, and it definitely *should* be called (as should DAQmx Start) before entering your acquisition loop.

 

The data overflow problem is probably pretty solveable.  Without seeing code, my first guess is that you aren't properly accounting for the different acquisition rates of AI and CI, maybe requesting the same # samples from both tasks?

 

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 7
(4,331 Views)

I am sorry for replying you so late becasue of the seven-day holiday.

If I set up a bufferd task, data will over flow,so I selected the on-demand mode at present.

 

And, when I select the signal channel, I found no matter I selected the SRC or GATE, the program have no difference. I used the inner clock, what is going on?

 

Thanks a lot for your help.

Best regards.

 

0 Kudos
Message 5 of 7
(4,283 Views)

Certain kinds of counter overflow errors can be caused by very high frequencies or noisy signals (that generate high-frequency edges).  I'd recommend some careful troubleshooting with MAX or example programs to investigate.  While troubleshooting, try using the "high frequency with 2 counters" measurement method at the beginning of config where you create your task.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 7
(4,255 Views)

Hi Kevin

Thanks for your help and patience.

The trouble may mainly be caused by the sensor, or my low programming level using LabVIEW.

Now, I have completed the testing system by using a little complex manual operation to make up the shortage of the program.

0 Kudos
Message 7 of 7
(4,247 Views)