LabView Core 2 - Exercise 2-3

[natasftw]

---

@joke77 wrote:

Why do you think that releasing the queue would be skipped if there was an error?

---

Generally speaking, inputting an error means you're not getting valid data.  You'll be working on garbage.  The vast majority of VIs start with a case structure that checks for error vs no error and handle their task internally.  For most of those, they pass out default values and the error itself in error cases.  I can't open up that VI to verify its functionality.  But, if it behaves like pretty much everything else, you'll skip the primary function if there is an error.

You also might notice that setup creates a situation where you won't execute the shutdown state if there's a queue error.  You'll bypass it entirely.

The other question, why do I think the top will behave differently:  if the top loop passes an error, I'd expect to see the same behavior from the release queue.  The second implementation means an error from either loop will act in this way.

If you want to verify the functionality of the release queue when there's an error state, put together a quick example that forces an error input and watch the memory manager to see if it's releasing the memory.  If it is, the difference between the two is minimal.

[William1225]

Hi billko,

Thanks to your suggestion.

I didn't notice that "Release Queue" has the property of "This node runs normally even if an error occurred before this node runs." until your suggestion.

But I'm a little confused what you said : "the dequeue says the same thing but it actually behaves normally"

The help file of dequeue doesn't say about that, and it will be skipped if previous error.

Do I miss somthing?

[billko]

---

@William1225 wrote:

Hi billko,

Thanks to your suggestion.

I didn't notice that "Release Queue" has the property of "This node runs normally even if an error occurred before this node runs." until your suggestion.

But I'm a little confused what you said : "the dequeue says the same thing but it actually behaves normally"

The help file of dequeue doesn't say about that, and it will be skipped if previous error.

Do I miss somthing?

---

OMG I meant ENqueue.  I'm SO SORRY.  (I never noticed if enqueue opposite end has this bug or not.)

[William1225]

Hi billko,

I still do not find the saying in the EnQueue, perhaps our LabVIEW versions are not the same(mine is 2014).

All the VIs in the Queue Toolkit except Release Queue will be skipped if there is a previous error after my trial.

[billko]

---

@William1225 wrote:

Hi billko,

I still do not find the saying in the EnQueue, perhaps our LabVIEW versions are not the same(mine is 2014).

All the VIs in the Queue Toolkit except Release Queue will be skipped if there is a previous error after my trial.

---

Maybe they fixed it.  I have to confess that I have LV 2013.  🙂

[Gregory]

---

@natasftw wrote:

 Also, why did you rewire the reference above the producer loop?  Keep the code clean and simple and just wire it straight through.

---

I just noticed that the "Producer/Consumer Design Pattern (Events)" that comes packaged with LabVIEW 2014 is wired this way as well.

[natasftw]

Interesting.  That doesn't make much sense.  The queue refernce is wired out of the clear errors and creates a tunnel at the far right.  It's not a shift register (nor should it be), so it's creating a tunnel that has no purpose.  If this already exists, what gain is there by wiring a second wire over the top?

Whether that matches the example or not, I'd still keep my code clean by using that currently unsused tunnel to pass the reference.  If that isn't how you do it, I'd dlete the wire creating the tunnel.  It's unused code currently.