LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reg : Is there any alternative for Queues ?

Hai All .....

            I am using a Queues for Data Recording and saving in to the file. But as per my requirement it is taking more time than expected. There is no problem with writing and reading from Queues but timing is the main problem in this. I wants know that can we use any another method to Read and write a data parallelly without using Queues ?

 

 

Thank you In Advance..... 

0 Kudos
Message 1 of 18
(2,648 Views)

Hi Praveen,

 


I am using a Queues for Data Recording and saving in to the file. But as per my requirement it is taking more time than expected.

What exactly is taking "more time than expected"? What is your expectation?

 


There is no problem with writing and reading from Queues but timing is the main problem in this.

Why do you want to replace queues when there is no problem with using queues?

 


I wants know that can we use any another method to Read and write a data parallelly without using Queues ?

Channels, notifiers, globals, locals…

But again: queues are most probably not the source of your problem! You should rather find the problem origin instead of removing queues from your code!

 

Btw. you forgot to show us your code (aka VI or snippet, but not just images) so we have no chance of advising improvements…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 18
(2,629 Views)

Just as Gerd says, Queues are most likely NOT your problem. They are as efficient as you can get if used right and allow to separate tasks into producer-consumer patterns that serve exactly the purpose to decouple the producer from the consumer so that the producer can keep churning away at full speed even if the consumer is sometimes temporarily held up by slow actions like having to create a new file to push the data into. 

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 18
(2,581 Views)

@Pathkula_Praveen wrote:

I wants know that can we use any another method to Read and write a data parallelly without using Queues ?


You can't. That's assuming you're talking about writing data to disk. If it's a performance issue i'll take a stab in the dark and guess you're opening and closing the file with every write?

/Y

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

Qestit Systems
Certified-LabVIEW-Developer
Message 4 of 18
(2,569 Views)

@Pathkula_Praveen wrote:

I wants know that can we use any another method to Read and write a data parallelly without using Queues ?


Where is this data coming from?  If a DAQmx task, then use the TDMS Configure Streaming VI to make DAQmx log the data straight to a TDMS file when you read it.  If anything else, then queues are definitely your best bet and you have an issue in how you are logging the data.


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 5 of 18
(2,511 Views)

If it's a performance issue i'll take a stab in the dark and guess you're opening and closing the file with every write?

/Y


I agree. Another stab in the dark could be that you're trying to send data one point at a time at a high speed. Of course without seeing any code it's impossible to know the problem. As others have said the problem is most likely NOT with the queues as they will transmit data faster than the data can be written.

0 Kudos
Message 6 of 18
(2,501 Views)

@Pathkula_Praveen wrote:

Hai All .....

            I am using a Queues for Data Recording and saving in to the file. But as per my requirement it is taking more time than expected. There is no problem with writing and reading from Queues but timing is the main problem in this. I wants know that can we use any another method to Read and write a data parallelly without using Queues ?

 

 

Thank you In Advance..... 


I was once told;

 

"Queues are almost always, almost full or almost empty." 

 

Almost full means the consumers is not keeping up.

Almost empty indicates the producer is not filling the queue faster than the consumer can empty it.

 

Yamaeda already took a wild guess at why the consumer is not keeping up.

 

It is possible to optimize queues but before I waste a lot of words on that topic...

 

"Show us the code!"

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 7 of 18
(2,499 Views)

@Ben wrote:. 

I was once told;

 

"Queues are almost always, almost full or almost empty." 

 

Almost full means the consumers is not keeping up.

Almost empty indicates the producer is not filling the queue faster than the consumer can empty it.

 


I like this - so simple and so true.

Message 8 of 18
(2,491 Views)

Show us what you've got thus far and we'll be able to advise solutions that should work.

 

Edit: Upload your VI, not a picture.

0 Kudos
Message 9 of 18
(2,473 Views)

As mentioned, your bottleneck is most likely writing the data to the file. Without seeing any code it is hard to say for sure. With this assumption, one way we have solved this type of issue in the past is to avoid processing the queue one element at a time. We create a simple state machine that is time based and when the timer expires, we flush the queue (flushing the queues returns an array of the queued elements) and process all of the elements at one time. When processing we create a single block of data that will be written to the file and only perform a single file write with that one block of data. This is much more efficient and works quite well.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 10 of 18
(2,444 Views)