error 1 at enqueue in a producer/consumer architecture

[flongnos]

Hello everyone,

I am using a queue-driven producer/consumer architecture, as shown in the screenshot below (which is a simplified diagram of what I want to do).

As you can see:

1/ In the producer loop, I read data from two LV2: Wafer Map and Current DUT

2/ In the producer loop, these LV2 are used as output of a sub-VI called "Wafer Map Change". This sub-VI, allows the user to modify the picture indicator "Wafer Map" located in the consumer loop, by double clicking on it.

3/ When the sub-VI has run, it outputs the modified picture indicator (Wafer Map) and the new "Current DUT" coordinates.

4/ The two variables are bundled and converted into a variant.

5/ The variant is subsequently enqueud in the "Main" queue.

6/ This variant is converted back inside the consumer loop, and the picture indicator is unbundled.

7/ Finally, the LV2 of the Wafer Map is written and the modified picture indicator is displayed.

This kind of data flow worked a while ago, but now I am faced with the following error (this is my translation from french):

Error 1 occurred at: Add an element at the end of the queue in Automatic Test Bench GUI.vi

Possible reasons:

Labview: One input parameter is not valid. For instance, if input is a path, this one may contain a character forbidden by the operating system, as ? or @.

NI-488:  The command requires a GPIB controller as main controller.

I have no idea how this appeared. But now I am stuck, and I would appreciate if someone can help me out with it.

Thank you.

Regards,

Florian

[JÞB]

I'ts impossible to tell from just a picture (I don't even know if you are configured to show coersion dots)

The obvious thing to look for is a crossed up type-def of type "Queue Data" but- you didn't typedef the cluster.  Hmmmm, start there and typedef that queue data cluster.  that should start you down the road to find which of those cluster constants has mis-ordered elements.  Wire the error chain too- Its impossible to see which enqueue element is throwing the error.  Turn on coersion dots if they are off.

[flongnos]

Hello Jeff,

I use a simplified diagram here,which is not functional and therefore can not show coercion dots.

The reason I don't use the real VI, is because it is is very large (250 sub-VIs) and the final diagram does not fit into my screen.

Here are some additional pieces of information:

1/ The enqueue element which is throwing the error is the one in the event structure.

2/ Coercion dots are turned on in the real VI, and none appears in the pieces of diagram considered here.

3/ I don't want to type-def the data cluster (bundle) as I will use the queue for passing other kinds of variants. In particular, I will pass enums, so that I can run queue-driven sequences in the consumer loop.

I hope it helps.

Thank you again.

Florian

[crossrulz]

---

@flongnos wrote:

3/ I don't want to type-def the data cluster (bundle) as I will use the queue for passing other kinds of variants. In particular, I will pass enums, so that I can run queue-driven sequences in the consumer loop.

---

A variant is a variant.  It doesn't matter what is contained in the variant.  So you should still type def that cluster.  You don't want somebody to accidentally reorder something on you and everything is totally broken.  I speak from experience here.

It looks like something is destroying your queue.  Where are you releasing your queue?  That's what we should be targeting.

Furthermore, you really need to work on your error handling.  Just trusting the Automatic Error Handler is a poor way to program.  Propagate your errors and explicitely deal with them.

[udka]

Please check this if it is useful
http://forums.ni.com/t5/LabVIEW/error-1-enqueue/td-p/2141428
-Can you give us a code that you can regenerate the same error that will be more helpful.

-I think you are using code similar to this link right? If so, please check the way the error handling and queue managed there.

https://decibel.ni.com/content/docs/DOC-4364

[flongnos]

Thank you for your inputs.

That's true that my simplified diagram did not show the error handling. And I guess my real VI has some weakness there.

I have updated the simplified diagram to show you best how it is really, including all LV2 and the error handling.

So as you can see, the queue is released only after the loop has been stopped (similar to the structure that you gave me udka).

The topic you advised me to look at does not seem to match my issue, as my queue is always valid. Or how could I check it?

Do you advise something else to monitor the errors?

Thank you.

Regards,

Florian

[flongnos]

Here are the files.

For the VI, I did not provide the sub-VI. I hope you understand.

[crossrulz · Accepted solution]

Your method for stopping seems suspect.  Say there was an error in the consumer loop.  That would stop the consumer loop and set the stop button to TRUE.  But that value of the stop button won't be read until the next iteration of the producer loop.  So if you decide to hit the Wafer Button, the queue was already destroyed, so you will get your error.  And all of those local variables just screams "RACE CONDITION" to me.

Make the Stop button's mechanical action set to Latch When Released.  This is the default setting for a button.  Then place the terminal inside of the event case (which you already have).  Wire a TRUE out of that case, OR it with the error wire to stop the producer loop.

You need to do is create a command to stop the consumer loop.  This command will be sent in the Stop Button value change case.  You should probably send this command after the producer loop just in case the producer loop created an error.

You can also use a property node of the stop button to set the Value (Signaling) property.  This will cause the event structure to trigger.  This will cause the producer loop to stop if the consumer has an error.

[cimballi]

Thanks a lot crossrulz!

You spotted this bad implementation, which is not exactly what I have in the real VI but very similar.

As I did it, an error occurring in the consumer loop will cause it to stop and the queue to be released. As a result, a "race condition" takes place, and enqueuing in the producer loop can not occur, triggering therefore an error.

Do you agree?

Besides, I will try your implementation tomorrow. It looks good to me. 

Regards,

Florian

NB: I used the wrong login, but it's still flongnos here

[flongnos]

Hello,

Great, the reason for my issue was bad handling of errors in producer & consumer loops.

I cleaned my code according to your suggestion, crossrulz, and now it's working perfectly again.

Thanks!

Best regards,

Florian