LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

non-simultaneous while loops

Solved!
Go to solution

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

0 Kudos
Message 11 of 16
(978 Views)

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

0 Kudos
Message 12 of 16
(962 Views)

@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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 13 of 16
(952 Views)

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.

---------------------------------
[will work for kudos]
Message 14 of 16
(920 Views)

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.

0 Kudos
Message 15 of 16
(911 Views)
Solution
Accepted by JamesDavies

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.

 

 

0 Kudos
Message 16 of 16
(848 Views)