Continuous acquisition buffered scan same number of samples

[sadmub]

I have created code that is HW timed and buffered...

Also, the PROGRAM on has LV 6.1 on that computer (yeah I know welcome to 2009, I am working on it)

Sampling rate 8kHz

number of scans 1k (4 channels)

buffer 1M

So I need this 1k window every time it is what I use to integrate the new position based on 2 angles (similar to Polar coordinates but different references, and with the noise I must have the entire 1k window to get smooth updates).  What is happening is I will get 1k occasionally and then when it sees "left over" in the buffer it gets it next time around, then it goes back to the 1k.  So I have one thread dedicated (and processor) dedicated to just getting the data and storing this Binary array into a local variable (this will also be used to store data at this rate deterministically for x seconds at a time when called).  I have another thread doing the calculations and displaying them at roughly 8kHz (this is all I need for the user to get a good real time estimate).  So when I pull the local variable I am not worried about race conditions just the latest for visual knowledge.  But I have to get every sample at the 8kHz in the main loop in order to do post processing.  I have done post processing and I know for fact I am not missing any samples during the save routine.

The Question...How do I get 1k samples (4 channels 4k total U16) every time not "sometimes".  I have tried some timing waiting for 125ms (8kHz/1Ksamples) and then the buffer gets backed up so I tried reducing this to 120ms and it just goes back to retrieving 1k, 1k, 1k, 65, 1k, 432, 22, 1k... not consistant...

So any suggestions, my code works "nice" as is when it only integrates over the smaller windows I get gitter but it still looks good.

Thanks ahead of time.

[Coq_Rouge]

Hi Sadmud.

Well if you get the job done in 6.1 just keep it that way. Anyway does 6.1 has the example finder under the help item in the toolbar? Then you should locate this two examples Cont Acq&Chart (Async Occurrence).vi and Cont Acq&Chart (hw timed).vi This examples will help you out. I guess you do not use hw(hardware) timing. I always use hw timing.

The two examples is inside the anlogin.llb

good luck

[sadmub]

Matter of fact I do use HW timed for the deterministic factors in the main thread.  I have looked at both those examples, no help.  Thanks

[Coq_Rouge]

I have done this kind of application several times. I guess you have a flaw in your code. If you post your VI we may fix your problem

[Ben]

Two points:

1) LV 6.1 had polymorphic queues. Use them instead of the local. That way the reader of the queue can fall behind (due to Windoze) but never miss the data.

2) I hope you are not updating your GUI at 8K! the fastest that makes any sense is about 30 Hz since the human eye can only work that fast.

Have fun!

Ben

[sadmub]

I have never used these posts before, do you read my post or just start posting stuff? Again, I am not worried about race conditions, queues use to much CPU relatively speaking.  I am not updating my GUI at 8k only whenever my non deterministic thread gets around to retrieving the local just for the eye.  PLEASE READ MY FIRST POST if you want to help.  I have my CLD I know most of these things, what I am asking for is only getting the scan to get 1k samples every time period.

Thanks

[Ben]

Well I want to help.

How I used to do that:

Producer/consumer architecture

Producer was DAQ. It regularly cheked the number of sample waiting in the buffer (in LV 6.1 that was done by doing a "read" but specify "zero" samples and check the backlog (I think it came of the top). When the number of samples waiting was greater or equal to what I wanted, I would read the number I wanted (another read operation with the ssample count not zero). The acquired data was stuffed in a polymorphic queue of the proper data type where the update data would sit until read by the consumer loop.

Its been years since I developed in LV 6.1 so hopefully none of the above is to far astray.

I really hope this helps!

Ben

[Coq_Rouge]

Is your problem the scan backlog output (or data remaining). You do not have to worry about this number. This because you will pick up these samples the next time you read your 1000 samples. And your data will come in a continuos stream. The important thing is that you have specified a adequate buffer size for your application in the AI config.vi. It is then you have overflow in this buffer that you will lose data. A few samples in the scan backlog is quite normal with a 8K sample rate. The daq buffer is a ring buffer, or FIFO

Message Edited by t06afre on 02-05-2009 04:01 PM

[Ben]

I had trouble finding a project in LV 6 that used the queue but here are screens hots of another app that used a "Dual-ported-Round-Robbin Buffer" to pass the data.

This is the structure of the DAQ loop

This is the check of the back log

This is reading the backlog and updating the round-robbin buffer.

Ben

Message Edited by Ben on 02-05-2009 12:01 PM