LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is a Wait timer needed in a consumer loop?

Solved!
Go to solution
Highlighted

@nonecure wrote:

That is what I always thought, but why would he see a big improvement on his 1 core machine when adding the wait 0ms?  We have 7 engines (dequeue loops) running on this machine.


Sounds to me like you are putting way too much into your queues.  When there is data in the queue, the Dequeue Element doesn't wait.  But in my quick tests, I'm not seeing 100% usage of a core, but I can see where it would though.


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 11 of 17
(381 Views)
Highlighted

Actually, we don't send that many commands to the queue and definitely not fast.  The only hit on the queue is before we start the servo, we send some strings to setup the movement profile.  When that is complete we then just send a start.  This is not time critical or high speed, we just queue up 4 commands per servo.

 

The contractor was saying that the dequeue holds on to a processing thread and the zero wait will release that thread.   So it this is not true, then I'm not sure why he saw better performance with the wait added.  He said the UI was slow even when not running a test until he added the wait timers.  

0 Kudos
Message 12 of 17
(372 Views)
Highlighted

Wait will release the thread allowing task switching, probably the 1 core virtual machine gains alot by it, in all normal circumstances it'll be a non-issue. I've certainly never heard of this one before, but it makes kind'a sense.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 13 of 17
(365 Views)
Highlighted

Are you trying to dequeue from the same queue in 7 different places? That would cause some loops to lock up because the queue would be empty. You can write to a queue from multiple places but should only dequeue in one place. For 7 engines you need 7 queues.

 

The LV scheduling process uses waits (even 0 ms waits), dequeues and notifier waiting for data, DAQ Reads, VISA Reads, Event structures with no events pending, and probably some others to "break" out of a loop and execute some other node which is ready. It did this long before multiple processor computers were available.

 

Something other than the Dequeue is causing the problems you are seeing.

 

Lynn

 

 

0 Kudos
Message 14 of 17
(343 Views)
Highlighted

Each queue has a unique queue name.

 

I am not seeing any problems.  The contractor I am using (NI Alliance Partner guru) told me that I needed wait states in my dequeue loops.  His reason sounded like it could be true, but I didn't quite believe it, so that is why I posted this.

 

I have a future application that will have 50 servo loops running in the background, so if there was any truth to this, it would be good to know.

0 Kudos
Message 15 of 17
(332 Views)
Highlighted

Curious... what version of LabVIEW?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 16 of 17
(319 Views)
Highlighted

2013 sp1

0 Kudos
Message 17 of 17
(305 Views)