counter Semi-Period buffered continuous Error

[RENN]

i'm measuring semiperiods/ or just the ON-time and OFF time of a signal.

its of approximately 58ms Pulsewidth (8ms ONtime, 50ms Off time). its given in the example that the ReadVI takes approximately 118ms = 4 semi-periods as shown in the Screenshot. please see the attachment. and the vi execution depends on the no. of semiperiods i intend to read. when i measured high frequencies, the while is executing very fast, nearly with 0-1ms execution rate. that means i must read more samples if i want to get very low semi-periods.

even though it works for sometime and generates an error : 200141

can anyone please help me with this...

[Andrea_Perin]

Hi Renn,

the Read VI in the while loop picks up the semiperiod values out of the RAM. If the periods get lower they will be often written in the RAM and your VOi (executingin a undeterministic OS like Windows) will try to retrieve them so fast as they are written. If  data are written in RMA faster than your VI can retrieve them than  you get the mentioned error since the automatic allocated ring buffer buffer overruns.

To avoid it, it is good practice to allocate a buffer bigger enough to avoid it. In your case this is set by the VI "DAQmx Timing" with the terminal "sample per channel " (read the help of this VI to know what it means when doing a continuous acquisition).

Now, you have set this buffer to "0", that means you don´t have any buffer for the acquisiton to compensate the different of speed between your VI execution and the rate with which the data are written in RAM. If you increase this buffer you should see benefit of you VI.

Be sure also that no concurrent programs are using PC resources while you execute the VI .

Best regards

Andrea P.

[RENN]

Hello Andrea

thanks for your reply...yea its the buffer size. i know this.. but even if i change the value (sample per channel) , i see always a constant value at the property node (DAQmx buffersize) inside the while loop. please see the BD. i dont know why this happens....

if i increase the buffersize the only difference is ~ the error comes after a longtime (in minutes). to show this error i just set the value of samples per channel = 0. if i set the buffersize=0, then also the Buffer -Property Node shows constant value (sorry that i couldnt open my vi now. i have tested it on another computer. the property node was always showing 10000)

i also dont understand why the execution time of while loop = Pulsewidth (if i read 2 samples)

its = 2 times pulse width if i read 4 samples....

please help!!!

[Andrea_Perin]

Hallo Renn,

the execution time of the whileloop is understandable. If you set you want to read 2 samples (that is like to say 2 semiperiods) the Read VI will deliver these values once they are available in the buffer. Two semiperiod vlaues wil be avaible when a complete period has been detected. That means Read VI need to execute this time : (N/2)*Thigh+(N/2)*Tlow+ SW overhead. It it not a case that yo observe 118 ms. This is 50+8+50+8+some ms of overhead.

I didn t understand what you meant  with the property node...can you explain it again?

Anyway if increasing the buffer just increase the time to get the error it means that you write faster than you can read and the buffer overfows. Maybethe semiperiods you ar reading are really to low so that your PC can be fast enough to retrieve so fast as needed.

Best regards

Andrea P. 

[RENN]

"Maybethe semiperiods you ar reading are really to low so that your PC can be fast enough to retrieve so fast as needed." i dont know its too slow or slow. what should i do in this case?? i have another problem also. if i use 2 counters at the same time, some of the notifiers in my application doesn't work. the whole apllication becomes slow. what could be the reason?

[RENN]

i am writing to the "send notification function". but i cant get any value at the output of the wait on notification function. and the whole application slows down.

[Andrea_Perin]

If the measurement you are taking requires more performance, then you need to work with another platform that can be fast enough for your signals (for example  Real Time or FPGA platforms, but you need the correspondent HW and LV modules to program them).

Do I Need a Real-Time System?

http://zone.ni.com/devzone/cda/tut/p/id/10342

 Developing Custom Measurement and Control I/O Hardware with the LabVIEW FPGA Module and Reconfigurable I/O Hardware

http://zone.ni.com/devzone/cda/tut/p/id/3261

They work with much more determistic OS (RT) or with no OS (FPGA) and you can reach loop rates that are not possibe in a normal windows enviroment.

For the second issue I cannot saytoo much without seeing your source code...

Best regards

Andrea P.