LabVIEW
error 1 enqueue
First, regarding memory leaks and the use of stop.
It's hard for me to believe that aborting the VI makes a memory leak. The principle reason for this (at the moment) is that I want a button to be able to abort the VI always, regardless of if one of the threads is hanging, which is possible depending on the amount of processing. The control thread actually had a notifier which tells the other threads whether to shut down or not (and provides time for them to do so... about 1 second and it knows of the other threads have terminated since they send responses). Hopefully, the stop vi won't be necessary once I spend enough time seperating out the things that can hang (long scans, processing, etc) but I had it in there now so that I could push a button (while hiding the abort icon) and still get the abort functionality. Anyways, if this causes a 'memory leak', that's kind of ridiculous. The question would be, if I do use queues, and do need to abort occassionally, how would I fix the queues so they worked on the next run of the program. I doubt this is the issue, but if it is, how does one go about fixing it in the case the VI is aborted.
Second, regarding simply connecting the control.
I've disconnected and reconnected the wire 5 times. As I said, I removed the LVG and now it's just a straight wire into the threads! Tracing the wire through, it's unbroken and the only way that could happen and I have an invalid thread is if it's not physically connected to the source control but instead to a second source that isn't initialized properly. Even worse, it's worked in the past!
I can show the full path to where it fails:
Well, I don't know how many levels of hierarchy you have between the two probes in your image, but I would confirm that inside SL-UI.vi, the "program communicator interface" control is connected to a required terminal on the connector pane. Then work one level up and check the same. I think you'll find the point where the cluster references become invalid.
Despite the comments from others, I'm pretty sure this is purely a wiring error and has nothing to do with memory leaks, disposing of queues, etc. Here's why: a queue refnum is an integer (with a wrapper around it). "Not a Refnum" is a special value similar to NaN. If the problem was that the queue was invalidated prior to calling the VI, you would still see those integer values as the queue refnums in the probe, they just would no longer be valid for queue operations. Instead, you're seeing an entirely different value (a value that's a typical default), which suggests that there's a wiring problem and the values aren't carried through to the VI that needs them.
EDIT: For what it's worth, I just did a quick test to prove this, note that even after the queue ref is invalidated it still has a value:
Thanks everyone so far for helping.
While I have checked my wiring, what I will probably delete everything and rewire this section to test out your hypothesis. The two probes are directly 'adjacent' to eachother through the subvi call. So there is only one level difference between them.
However, this is even more interesting to me:
Okay, so what's happening here. All of thes SL* vi's are pretty symmetric: They bring in the pci and then with a normal tunnel pass the pci into a while loop in each of the vis. Now, as I watch right after the tunnel on the probes for each of these vis, I see them (well, all of the except the UI one) flicker to occassionally what the probe [6] says, though normally they are correct. Maybe this is just a bug in how the debugger works when polling the information inside the queue. I dunno, but it's pretty disturbing. Perhaps someone can tell me if this means I'm messing up somewhere. I thought it might be because I use these queues in different 'execution environments' so I tried to go in and change all the execution environments to the 'same as caller' and what not. That didn't seem to do anything. I'll continue debugging.
As I said, I've had this issue before and it just randomly comes and goes in my program.
