12-16-2010 02:49 AM
In menu advanced/synchronisation/queue_operations you'll find those queue nodes. Optain a named queue outside of your loops with the data type your loop delivers. Feed the queue wire to both loops. In the generator loop, append a dataset whenever it is available. In the storage loop, use 'Get queue status'.'#elements in queue' to check how much data is available. If it is enough, use 'flush queue' to get all the datasets and store 'em. Do not forget to release the queue when you're done. Search the examples for queues or the producer-Consumer-Template.
HTH!
Greetings from Germany!
--
Uwe
12-16-2010 09:40 AM
Yes, of course that (writing data in bigger chunks) would make a difference. Even if you were to write 1 byte to the disk what happens is that a disk read is done for the smallest chunk (called a cluster), then the data you wish to write is overlayed on that read cluster and then the data is written back to the hard drive. With caching, this can be improved, but still has overhead.
So, what I've done in the past is to create a string, appending new data to that string and when that string gets to be a certain size (or maybe a timeout has occured), write the data stream to the file. IIRC, usually a cluster is 8192, but that can vary.
A
12-16-2010 10:28 AM
@JamesDavies wrote:
How do I do that, adding data to a queue? At the moment the data is written after each loop iteration - is there a simple way to simple store the data in a buffer and write it all every 10 loops for example?
The simplest way if to use Build array with the data and send it through loop iterations with a shift register. Then, as you write the data (every second, every 10 sec or so), you simple send an empty array to the shift register.
A slightly more advanced and prettier solution is to send the array as an event or to a queue and handle that.
/Y
12-17-2010 10:58 AM
It sounds like there is probably something really inefficient going on in your code. Would you mind posting your code for us to help you? (screenshot + file)
We would be able to give you a lot more help that way.
12-17-2010 11:22 AM
The code is a wiring mess, you wouldn't appreciate having to have a look at it.
All the suggestions have been very helpful, I havn't had time yet to see how big an effect the buffering options have.
01-20-2011 06:11 AM
So, I found out why the program was so limited in speed.
To get high frame rates from my camera I would set the area of interest to a limited size. This new size was not getting updated in the IMAQ image utility - so it was still processing pixels that wern't there as it was expecting the full size image.
Having remedied this I am now able to record linear intensity profiles over the 1280 pixel width at over 100 times per second.