回應： LabView Core 2 - Exercise 2-3

[joke77]

In the exercise book LabVIEW Core 2 - Exercises, there is exercise 2-3 "Producer Consumer - Error":

There is a producer and a consumer loop. And the goal is to generate artificial errors to learn error handling.

There is a button to simulate an error "15" in the producer loop, and a button to simulate an error "5000" in the consumer loop.

However, I often see "Error 1 occurred at Enqueue Element At Opposite End" when clicking the button for simulating an error in the producer loop.

I think it is because after an error in the producer loop, the queue is released. But the consumer loop is still running for a short time, and it wants to use the queue (which has been already released).

Whouln't it be better to first merge the error wires of the two loops and to afterwards release the queue?

[natasftw]

I'm mostly having to guess what you're seeing as you didn't post the example code so we could all see it.

You are suggesting merging the error wire from both loops.  You're seeing an error take place in one of those loops.  It sounds like you have a misunderstanding of how dataflow works.  In LabVIEW, a node will execute when it receives all of its inputs and not until.  Then, it will work its magic.  Once it's finished, it'll make all of its outputs available simultaneously.

Think of what that means for your loop.  If you add anything after the loop, that node won't receive any input from the loop until the loop is finished.  It will have zero impact on what is handled inside the loop.

If I remember that example correctly, the consumer loop stops when the dequeue element throws an error.  The error you're concerned about is HOW that code functions and avoids an infinite while loop.  If it didn't error, what other stop conditions do you have in the consumer loop?

[Gregory]

When I open the core 2 folder I see folders named LV2M1 through LV2M21 which I think is the module number. Which folder are you referring to? LV2M10_Handling Errors?

[William1225]

I'd like to ask the similiar question about the error handling in the producer-consumer loops.

I usually check the error as entering the loops but I'd like to know if there are some problems in my architecture.

Could someone please give some suggestions or advices? I would appreciated a lot!!! 

[Gregory]

Hi William,

rather than wrapping things up into a case structure, a common way of detecting the errors is to put a VI after your state machine case structure in the consumer loop. This VI can look for errors and enqueue the next state (either an error handling state or a shutdown state) and you can communicate this back to the producer loop using the user generated event.

[joke77]

Sorry for not posting the code! (I thought everybody had run through the exercise books I have...)

Here is the official solution:

And here is my suggestion:

I think in the official solution, the queue gets released too early. (the consumer loop could still need it)

[natasftw]

Your solution creates a situation where you may not release the queue. If you pass an error into it, it will skip that.  That happens if either loop experiences an error condition.  Also, why did you rewire the reference above the producer loop?  Keep the code clean and simple and just wire it straight through.

If you're concerned you might lose a few elements in your queue with that release, the fix is not to change the order of the merge and release.  You've just created a new problem.  Instead, you can add a while loop before the release that operates with a Get Queue Status and stops with the condition that the queue's size is zero.  That loop will execute until the queue is empty and then move on to the release.  With this, you're not leaving yourself with the possibility that you'll never close the queue's reference.

[joke77]

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

[William1225]

Hi, natasftw,

I'm just curious why the upper loop wouldn't skip the Release Queue if there is an error?

[billko]

---

@William1225 wrote:

Hi, natasftw,

I'm just curious why the upper loop wouldn't skip the Release Queue if there is an error?

---

According to the help file, you are correct in assuming it will run even if there is a previous error.  In practice, I believe the dequeue says the same thing but it actually behaves normally.  So maybe there's a chance that release queue doesn't behave properly, either.  Other than that, I think your assumption is correct.