LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView Core 2 - Exercise 2-3


@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.

 

 

0 Kudos
Message 11 of 17
(1,729 Views)

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?

0 Kudos
Message 12 of 17
(1,648 Views)

@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.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 17
(1,624 Views)

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.

 

0 Kudos
Message 14 of 17
(1,613 Views)

@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.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 15 of 17
(1,576 Views)

@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.

0 Kudos
Message 16 of 17
(1,364 Views)

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.

0 Kudos
Message 17 of 17
(1,319 Views)