Dequeue element freezes

[ManzanoResearch]

I have four different queues that I use to handle my UI, program control, data acquisition, and data logging. These queues are all in a class and can be accessed by all VIs in the project. I have a version of this code that runs perfectly. However, I needed to add some controls for a specific functionality. When I added these controls, I modified a few states in my control VI and added a few new subVIs. These subVIs have been added to the appropriate classes and there are no overt errors I can see with this change. However, the acquisition queue (which I did not modify from the version that works) now intermittently fails to dequeue elements. I know for a fact that the elements are being enqueued (I didn't change the enqueue process). When I run the "show execution" the program gets to the dequeue element block and stops. There are no errors generated. I can get the main exit command to work. It sends and exit into the acquisition queue which does get dequeued. However, during program execution, commands like "update settings" fail to dequeue and execute.

Thanks for your help.

[Bob_Schor]

Since you modified working code and it is now not working, you probably did something that messed up the Queue.  If you want us to look at your code and try to figure out where the problem might be, please atttach (all of) your code.  Otherwise, please tell us how many VIs are in your Project and the size of each of their Block Diagrams -- we'll make a guess as to the VI # and the X/Y coordinates of the bug on that Block Diagram (I hope you know I'm kidding about this ...).

Bob "My ESP is Not Working Today" Schor

[ManzanoResearch]

Bob,

Unfortunatly, the computer with the code on it is a stand alone machine, so I can't get the code or the screenshots uploaded. However, I have traced the problem down to the dequeue element block. Have you ever heard of a case where this block seems to freeze without throwing an error?

Thanks

[Kevin_Price]

Any chance that during your edits, an accidental change is causing some other part of the code to dequeue from that same queue?  Let's just suppose another part of the app is also listening to that queue.  You mentioned that its an "acquisition queue" and you're sending commands like "update settings."

I picture an acquisition loop that first attempts a dequeue with a 0 (or very short) timeout.  If it times out without finding anything to dequeue, it moves on to do its normal acquisition.  Acquisition often requires a little bit of time to accomplish, so if anything gets queued up *during* acquisition, the *other* listener will dequeue it before the acquisition process iterates around to try again.

Just a wild-ish guess.

-Kevin P

[ManzanoResearch]

Kevin,

It's a good guess, and its actually one of the first things I looked for since it got mentioned on some other threads.

I don't think this is the problem because of when the problem happens.

When I run my code, the flow is initially:

-User pushes Run in labview

Four queues are created, Control, Acquisition, Logging, and UI

Each queue is immediately loaded with the 'initialize' state

All queues execute 'initialize' (For Acquisition, the state is effectively an idle until a new element is dequeued)

The UI (Master) queue then updates front panel and adds 'update settings'

Control and Logging smoothly execute the 'update settings' state and wait for further instructions

Acquisition freezes at the dequeue element block and fails to execute the rest of the 'update settings' state

At this point in the code, there has been no data taken or stored, and there are no other dequeues that interact with the Acquisition queue.

Thanks

[Bob_Schor]

To follow up from Kevin's suggestion, the Dequeue, by default, has a "Wait Forever" (actually, it's technically "wait approximately 7 weeks") before it times out.  Try wiring 1000 ("Wait 1 second before throwing an Error") (or some other "reasonable" time) into your Dequeue (it's the input between Queue In and Error In) and see if you have a timing issue/race condition.  You might also put an Index Indicator on the Dequeue Loop to see at which Dequeue it "gets stuck" -- it would be very interesting if it was a consistent low number (like 0 or 1) ...

Kevin and I would be very interested in what you discover!

Bob Schor

[ManzanoResearch]

Bob,

I agree that there is probably some kind of timing issue. I have run the code with the main VI running in 'watch execution' mode and the Acquisition subVI running at regular speed. When I did this, it successfully, dequeued the 'update settings' state, but then froze dequeuing the following state. Now that I think about it, I'm wondering if it's somehow trying to dequeue the element before the element has been enqueued. It then waits forever (or about 7 weeks) for the element to appear, but because it is frozen up, it never sees when the element is actually added.

[Bob_Schor]

---

@ManzanoResearch wrote:

Bob,

I agree that there is probably some kind of timing issue. I have run the code with the main VI running in 'watch execution' mode and the Acquisition subVI running at regular speed. When I did this, it successfully, dequeued the 'update settings' state, but then froze dequeuing the following state. Now that I think about it, I'm wondering if it's somehow trying to dequeue the element before the element has been enqueued. It then waits forever (or about 7 weeks) for the element to appear, but because it is frozen up, it never sees when the element is actually added.

---

A Dequeue doesn't work that way!  The Queue, itself, is asynchronous, so unless there is something on the Error Line in front of the Dequeue that is preventing it from running (because it has not run, Principle of Data Flow 101), then whenever anything is put on the Queue (or after 7 weeks, whichever comes first), it will run (or Error Out).  [Sorry, I no longer have your code open in front of me ...].

Bob Schor

[natasftw]

---

@ManzanoResearch wrote:

Have you ever heard of a case where this block seems to freeze without throwing an error?

---

Yes.  This happens every time you get to the Dequeue VI with an empty queue.

You've likely traced the application to where the problem is being shown but have followed a bit of a red herring.  It's far more likely you're running into an issue with the enqueing.  You've added states.  You've added subVIs.  You've added logic. It's quite possible you're bypassing logic that once ran (after all, isn't a key point of states that you can change the order in which actions operate?)  I'd wager if you put a queue status in front of the dequeue and checked to see how many elements exist, you'd see the answer is 0.  If that's the case, you'll want to follow the loops that should be adding elements to the queue.  Presumably, they'd still be operating now.  If not, you can follow the logic when you perform the action you expect to fill the queue.

Check that logic.  See what happens.  You'll likely have a better chance to narrow down what's causing the problem than focusing on the dequeue.

[natasftw]

Bob, 

It sounds like his loops are somewhat dependent.  If they're not purely asyncronous, there's a very high probability the dequeue is working exactly as he says.  It's waiting on an element that isn't being enqueued.

As he can see this issue in highlight execution, the chance of a "race condition" is unlikely to be the cause as highlight execution will force some form of order so he'll see the same order each time.  Rather, it's probably an inversion of when the element gets enqueued/dequeued.

_____________________________________________________

Also OP, why would a standalone PC cause an issue with sharing the code so we can help debug?  You're not seriously keeping your entire code base on a single PC knowing it would be lost if anything happened to the PC, are you?  If you are, offloading the code to share it here is a good first step towards duplicating the code for your own peace of mind.  I assume this also means you don't have source code control in a way that would allow you to roll back changes to see if removing any specific new state would get rid of the hang?