Producer/Consumer Trouble: Multiple Loops/Queues

[NECO2012]

Hello,

Please refer to my previous post <http://forums.ni.com/t5/LabVIEW/What-is-the-best-way-to-switch-between-multiple-image-buffers/td-p/1...> for more insight on the matter. I was told to try a Producer/Consumer architecture, so I decided to go ahead and do so.

After doing plenty of research, I have come back to ask for some help.  I have decided to try and implement three loops. The reason for this is because I figured each loop's timing duration could be controlled independently as they should be. One loop deals with all user interactions.  One loop deals with data acquisition.  One loop deals with processing.  I hoped that this would help everything, yet obviously made things much more complex.  I have created a queue for each loop.  I have not finished the complete project, but it looks like everything should run fine where I have stopped.  However, one of my states that I have not enqueued gets enqueued, and I have no idea why or where that comes from.  There is an error under the variant data that says 

'status' -> TRUE
'code' -> -6
'source' -> "Error : Invalid Args"

However there is no error from the wiring.  Also when this error comes up, the random state gets passed through.

The other weird thing is the number of elements enqueued jumps very rapidly when I pretty much do nothing.  I'm not sure if this is common.

Before I post any pictures or anything, I'd like to get some insight on this error. 

Also, I believe I saw this in a previous post about QSM's but would like to ask a question.  Attached are two pics.  Queue 1 is the way I have things set up.  Queue 2 is the way I've seen things set up.  Can someone tell me if Queue 1 is a bad approach and why?

[Hooovahh]

Your Queue1 image is the wrong approach because it is a race condition at the moment.  If you run that VI the way it is, there is a possibility that you will perform the Enqueue before performing the Dequeue.  Queue2 keeps the data flow so that the Enqueue will only happen after the Dequeue.

If states are being added and you're not sure why, try putting break points in the locations that you enqueue states.  This will help you see where, and in what order states are being added.

[crossrulz]

---

NECO2012 wrote:

There is an error under the variant data that says 

'status' -> TRUE
'code' -> -6
'source' -> "Error : Invalid Args"

---

This sounds like you tried to cast a variant into something it can't do.  For instance, you turned a Boolean into a variant and then tried to turn the variant into a numeric.

---

@NECO2012 wrote:

The other weird thing is the number of elements enqueued jumps very rapidly when I pretty much do nothing.  I'm not sure if this is common.

---

No, that is not common.  Though, it really depends on your code.

---

NECO2012 wrote:

Also, I believe I saw this in a previous post about QSM's but would like to ask a question.  Attached are two pics.  Queue 1 is the way I have things set up.  Queue 2 is the way I've seen things set up.  Can someone tell me if Queue 1 is a bad approach and why?

---

It's not really a bad approach, just not preferred.  But I'm also using the assumption that you will be using your error clusters to keep the data flow.  Basically, it is bad practice to branch a reference wire, especially for a serial set of functions.

[NECO2012]

Sorry not attached is other things such as Parameters and error wire.  Those require a shift register around the while loop.  Wouldn't this ensure the dequeue then always comes first?

[NECO2012]

So I tried using breakpoints and all it told me was what I already know.  Here's what happens (in picture).  By the way this is just very basic form of what happens.  I just tried putting something together relatively quickly to see if someone could help.  It goes through the while loop and does go through watch for events state first.  Then it goes to that state in the case structure and things are fine.  The watch for events does get enqueued.  However when stepping into next iteration, it goes through the dequeue and dequeues out the wrong state.  Then it does not follow what it's supposed to do (i.e. enqueue the watch for events state) and just keeps running through this other state.

[crossrulz]

State machines are really hard to debug via pictures.  Can you post some real code?

[NECO2012 · Accepted solution]

I have figured out what happened.  The other loop was not handled properly and sent the random state to the main loop.

[RavensFan]

---

@Hooovahh wrote:

Your Queue1 image is the wrong approach because it is a race condition at the moment.  If you run that VI the way it is, there is a possibility that you will perform the Enqueue before performing the Dequeue.  Queue2 keeps the data flow so that the Enqueue will only happen after the Dequeue.

If states are being added and you're not sure why, try putting break points in the locations that you enqueue states.  This will help you see where, and in what order states are being added.

---

Not True.  That Enqueue will occur after the Dequeue.

There is a possibility of something inside the case structure enqueuing or dequeuing before or aftern the enqueue to the righthand side, but nothing shows what is happening to the branch of the queue wire going to the case structure.

[Hooovahh]

---

@Ravens Fan wrote:

---

@Hooovahh wrote:

Your Queue1 image is the wrong approach because it is a race condition at the moment.  If you run that VI the way it is, there is a possibility that you will perform the Enqueue before performing the Dequeue.  Queue2 keeps the data flow so that the Enqueue will only happen after the Dequeue.

If states are being added and you're not sure why, try putting break points in the locations that you enqueue states.  This will help you see where, and in what order states are being added.

---

Not True.  That Enqueue will occur after the Dequeue.

There is a possibility of something inside the case structure enqueuing or dequeuing before or aftern the enqueue to the righthand side, but nothing shows what is happening to the branch of the queue wire going to the case structure.

---

Sorry I looked at the VI too quickly and assumed that it was coming from the input terminal of the Dequeue to the input terminal of the Enqueue.  You are correct.