SubVI locks up main VI

[P@Anand]

When you configure the Front panel close event, you still have the option to discard it. If you still want to close it, just pass "True" from that event and in the other events pass "False".

[Yamaeda]

---

P@Anand wrote:

No it keeps the X ON.

---

True, but the screenshot already had it on, so toggling it will disable the X. 🙂 I should have been clearer.

/Y

[bmishoe]

I still cannot get this thing working right...I added a while loop back in and took advantage of the Panel Close? event:

In the case in the screenshot, the boolean is set to true.  In all other cases I set it to false.  But I still get the exact same behavior.  This sub VI is somehow not finishing processing and it's locking up my main VI.  I must be missing something obvious but it's not apparent to me...any other thoughts?

[Yamaeda]

Well what happens in the 2 other sub-vi's? Are you certain the queue has something to dequeue or is it waiting forever for an item?

/Y

[bmishoe]

It was the queue indeed!  I commented out the dequeue operation and then it worked perfectly.

crossrulz had mentioned this a few replies ago.  Kudos to both of you.

thanks for all the help.

[bmishoe]

so hopefully a final question then is....why does the dequeue element function lock this up, even when I exit the loop?  I redrew the loop as follows....so the dequeue element and the event structure - which has a panel close? event registered - are both inside the while loop.  So when I close the panel, shouldn't it terminate the loop and therefore terminate the dequeue element routine?

I found that if I add a 1ms timeout to the dequeue element function, the code below works fine.  And that's fine for my situation, as I don't need the data to have a 1 ms resolution.  But I'm still curious why this was necessary....

[Yamaeda]

What's enqueing to that queue? If nothing enqueues you'll get stuck waiting. The timeout is ok if it's a realistic scenario that this VI runs without anything enqueing (and possibly in other cases should something mess up, but then with a higher value, like 2000)

/Y

[crossrulz]

---

@bmishoe wrote:

so hopefully a final question then is....why does the dequeue element function lock this up, even when I exit the loop?  I redrew the loop as follows....so the dequeue element and the event structure - which has a panel close? event registered - are both inside the while loop.  So when I close the panel, shouldn't it terminate the loop and therefore terminate the dequeue element routine?

---

The Dequeue Element defaults to a timeout of -1, which is wait forever.  So if you never enqueue something, the Dequeue will sit there forever waiting for someting to be queued up.  So your loop needs two things to iterate: an element to be dequeued and an event to happen.

What is the point of the Dequeue?  What is this VI trying to do?  It seems like bad design for anything I can think of.

[bmishoe]

There is an FPGA I am monitoring by reading register values via a telnet connection from LabView to the FPGA.  As data values come across the telnet connection, they are put into a queue.  This loop with the case structure dequeues an element and lights up various indicators accordingly based on the address.

The event structure tracks history and basically edge detects any changes on the indicators.

I see what you're saying about the dequeue element waiting for some value in the queue, but should the loop stoppage override that?

[Yamaeda]

---

@bmishoe wrote:

 but should the loop stoppage override that?

---

That is for you to answer, how do you want your program to function? 🙂

/Y