LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Excessive time to empty queue in consumer loop

Solved!
Go to solution

I am working on a VI used to screen analog to digital converters over temperatures from room temp to 175C.  I have set this up with a producer and a consumer loop.  The producer loop makes all the measurements while the consumer loop is used to write all test measurements to a spreadsheet file. There are 23 measurements taken and recorded each second.  The test is run for approximately 60 minutes.

 

Initially, I had trouble with data in the queue being lost when I stopped the VI.  I fixed this by making sure the queue was completely empty before stopping the VI.  Now my VI will continue to run long after I have pushed the stop button.  I have let it run for up to an hour and finally aborted the operation and still lost many of the measurements on the end of the queue.  From my reading on the forums, this is because of the overhead to write to a measurement file.  Opening and closing the file every second is slowing everything down.

 

I have seen some examples of creating an array of measured data and only writing every 100 samples or so.  Can anyone help me see how I might implement something like this in my code?  Is there some other reason it is taking so long to write all of my test data?

 

Thanks,

Matt 

 

0 Kudos
Message 1 of 5
(3,203 Views)
Solution
Accepted by Nelzone

You need to use the actual File I/O functions.  What the Write Measurement File express VI is doing is opening the file, writing the data, and then closing it.  When you are doing this repeatedly, you get a really slow performance.  So you need to open the file before you consumer loop and close it after the loop.  You will then be able to write inside of the loop as much as you want.  But now you will have to format the data yourself.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 5
(3,197 Views)

Your stop button is "switch until released", meaning it will revert back to FALSE as soon as you release it. If you release it while there is still data in the queue, the lower loop will never be able to complete and will spin forever (unless you press stop again once the queue is empty). This does not look like good design.

 

Also you have a huge amount of duplicate operations in the upper loop. You could reduce the current code to 10% of what it is by using array operations. Start with an array of booleans in a single shift register. Use a parallel FOR loop with N instances to ensure that all ptbypt means keep their own history, etc.

0 Kudos
Message 3 of 5
(3,181 Views)

Thanks for the heads up on the switch.  Somehow it changed type on me.  Thanks also for the suggestion on using arrays to reduce my code.  I am still a newbie as you can probably tell.  Still learning the basic tool pallette and basic best practices.  I have struggled quite a bit early on, but this forum has been a great resource.

 

Matt

0 Kudos
Message 4 of 5
(3,157 Views)

@Nelzone wrote:

I am still a newbie as you can probably tell.  Still learning the basic tool pallette and basic best practices.  I have struggled quite a bit early on, but this forum has been a great resource.


3 Hour Introduction
6 Hour Introduction
LabVEW Basics
Self Paced training for students
Self Paced training beginner to advanced, SSP Required
LabVIEW Wiki on Training
Learning NI
Getting Started with NI Products


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 5
(3,126 Views)