error 1 enqueue

[majoris]

So I use queue to pass data between processes in my vi. There are lots of queues and lots of processes. Each queue has a typedef'd cluster as it's little queue payload. The overall topology of the vi is this:

Deep inside one of the vi's on the right something like this is called:

When I run this, the enqueue gives me an error 1. Now, it didn't always give me an error 1. It used to work. However, as I've built up this vi, I've seen this problem often that I get error 1 when I enqueue to these queues. Sometimes I just run the vi a few times, or open and close stuff or save stuff and the error goes away (magically ~,~). My guess is it has to do with the fact that I change the type definition at some point and this change isn't digested too well by Labview. Does anyone else have this issue and is there any cure? Could it be something else I'm overlooking?

Thanks!

[crossrulz]

I usually see that error when the queue reference is invalid.  I would look for some place where the queue reference is not propagated properly (0 iteration FOR loops come to mind) or the queue is closed in parallel to this code.

[majoris]

I guess I forgot to mention that (and I guess it IS more relevant): The cluster of queues I have is valid up until I pass it down into subvis.

So yeah, it has to do with the queue boggling up somewhere. I don't understand why. To give more context the cluster of queues is a typedef also containing the queue elements that are generated off of typedefs.

At [9] below is right before I pass the cluster to the subvis and [2] is inside a subvi, right after the input control.

[P@Anand]

It happens sometimes when you use the LV2G in many places you may try to read the LV2G with the Write Enum connected (I did that many times). When you do that empty elements will be updated to the LV2G and it becomes invalid. Check the instances of the global with care

[majoris]

While I do use the global in the first image, I actually have yet to use the global and instead have been using a wire. The queues appear valid after leaving my init function (since after using init, I simply pass the updated global structure). They just get very sad falling right into subvis and then produce these error 1s occassionally. I could actually try replacing my usage of the wires with the global. I wonder if that would actually help ~.~.~.~.~

[crossrulz]

P Ananad,

  Good catch.  I didn't notice that FGV (or LV2GV, whatever you want to call it).

majoris,

  Can you share your FGV there?  My guess is that the task enum is not required and the default will close the queues or something else.  I have screwed those things up enough times.

EDIT:  Ok, you updated while I was typing.  Where are the queues being closed out?  Could this code be getting executed before you want?

[majoris]

Just for certainty, I removed the global and now just use a wire exclusively and get the same behavior. Even before, I was probing right after the FGV and found the queues to be valid. It was only once they were passed that they stopped being global.

What kind of situations can close a queue? I never explicitly close them. Can this be an issue? Can the fact that I pass them to many different vis be an issue?

[crossrulz]

---

@majoris wrote:

I never explicitly close them.

---

I would concider that a memory leak.

[P@Anand]

Are you usnig the same code whatever you showed at the top? I see a stop function there what is that guy doing? I suspect that is closing evrything and you get invalid queue reference.

[crossrulz]

---

@P Anand wrote:

Are you usnig the same code whatever you showed at the top? I see a stop function there what is that guy doing? I suspect that is closing evrything and you get invalid queue reference.

---

I agree that it shouldn't be there.  But I don't see that causing the problem (unless it's due to the memory leak we mentioned earlier).  The STOP is basically the same as hitting the Abort Execution button.  Not a nice way to end your application.  The VI should be able to end on its own.