10-19-2006 04:05 PM
10-19-2006 04:46 PM
10-19-2006 08:33 PM
10-19-2006 11:46 PM - edited 10-19-2006 11:46 PM
the problem i'm having with this part is that I can forsee this situation --- if the 'dequeue while loop' is running at a much faster rate than the FOR loop, it should generate an error if it tries to dequeue an element that isn't there yet. If that happens, that loop will stop. if the FOR loop then dumps something into the queue, the program will hang because the queue will never be empty.
altenbach wrote:In the while loop, just stop when the dequeue creates an error. This means the queue is empty and has been released. 🙂
Message Edited by zskillz on 10-19-2006 11:54 PM
10-20-2006 02:13 AM
@zskillz wrote:
So i read a bit more about the 'dequeue element' function, and as I understand it, since there is no timeout wired to the dequeue element function, it will wait forever, thus the race condition I suggested above can never happen!
Yes, you got it! 😄
10-20-2006 03:36 AM
10-20-2006 11:24 AM
10-20-2006 11:46 AM - edited 10-20-2006 11:46 AM
As I've thought about it a bit more, there's a few things that surprise me... first, the reason the 'dequeue element while loop' errors is not because there's nothing in the queue, it's becaues the queue has been released and it's trying to access that released queue... However the problem I have is this --- Even though there's no timeout wired to the dequeue element, I still would think that the while loop that contains it would continue to run at whatever pace it wanted -- and as i said before.. most of the time, it would find that there is nothing to dequeue, but once in a while, something is there. however, it seems that this loop only runs when something has been enqueued. the reason I say this is illustrated in the next code sample MODv2 that's attached below. I've added a stop button to the "queue size while loop" so the program runs until that is pressed. I've also added a simple conditional in the "dequeue while loop" that generates a random number if it a button is pressed... but this button is totally non-responsive... which means to me that the "dequeue while loop" isn't actually continuously running, but only when an element is added to the queue. this still seems almost like the 'dequeue while loop" waits for a notifier from the queue telling it to run. can you explain this to me? because it is different from what I expect to be happening.
@altenbach wrote:
@zskillz wrote:
So i read a bit more about the 'dequeue element' function, and as I understand it, since there is no timeout wired to the dequeue element function, it will wait forever, thus the race condition I suggested above can never happen!
Yes, you got it! 😄
Hi Rasputin, I'm using LV8. I assume that was your problem, but who knows. I've attached a pic of of altenbach's solution since it's what I needed.
@Rasputin wrote:
I tried to open your VIs but it doesn't work. LV is launched, the dialog box (new, open, configure...) opens and then... nothing. Not even an error message. I guess it isn't a problem of LV version or a dialog box would appear saying this. Could you, please, send a image of the code?
Thanks,
Message Edited by zskillz on 10-20-2006 11:49 AM
10-20-2006 12:31 PM
Labview function define the default behavior for each input if it is not wired. If you create a subVI, you can set reasonable default values for each control, which then would be used in case it is not wired.
The default value for the timeout in the dequeue function is intentionally defined as "-1" (not as zero!), meaning that it will wait forever until an element is available (as described in the help) if it is not wired. You can overwrite that with any timeout value you want by connecting a diagram constant or control.
The more you learn about LabVIEW, the more you appreciate the amount of thought that went into the design. Things are really optimized for the most typical use and greatest functionality. If there is no new element to process, why spin the loop? 😄
10-20-2006 01:04 PM
but that's exactly my question/problem.. If other controls are placed in that loop, then it would need to spin. -- and I'm surprised that it doesn't if that's the case.... I assume that this is LV's way of telling me that I should not put other controls in that loop, but instead somewhere else?
@altenbach wrote:
The more you learn about LabVIEW, the more you appreciate the amount of thought that went into the design. Things are really optimized for the most typical use and greatest functionality. If there is no new element to process, why spin the loop? 😄