I can see many examples of this happening in various parts of my code where queues either become invalid while waiting or are invalid when passed to a subVI, even though a release was never called and their creator VI is still in memory and supposedly 'reserved for run' still. I think the LV engine get 'confused' and screws this up. As you can see from the error, the 'main.vi' has been spawned from a template 422 times and the reentrant subVI that got the error is one of 34 in memory right now, all listening to their own 'version' of this queue. The interesting thing is everything seems to work well for a long time and then it all goes to heck. The VI that get the error is running as a sub VI of the same VI that called the VI that created the queue. Since all of these VIs are part of the main VI, i don't see how it is possible that the queue reference would be automatically removed from memory. When the listener quits, it passes its error cluster to the sub VI that destroys the queue. The structure of my code has a main vi that calls a sub VI to create the queue and then passes the queue ref to another sub VI that listens to the queue. In my case, however, I don't think that is possible. That is definitely a way to cause a queue to be deallocated. The work-around it to make sure the VI's that creaed the queue don't go idle until after the queues is destroyed. So if the Queue was created in a VI that goes idle the queues it created are destroyed. When a VI is no longer running, all of the resource tht were allocated by that VI are destroyed. I'm not sure if the following may be what is hitting you but you did ask for "other ideas" I thought labVIEW used a GUID to name unnamed queues so they could never step on each other, but maybe because I have so many, the 'name' is getting reused? So, there are many many instances of this queue (all unique, supposedly) that exist within each tree of reentrant VIs. I have a large number of reentrant VIs running and I create a lot of unnamed queues that I pass inside a cluster to sub VIs. I have a sneaking suspicion that there are some latent bugs in the queue feature. So, there is no way that cleanup VI could execute before the VI that is waiting. But, I have searched all the VIs and the only one where the queue is destroyed is in the cleanup VI that comes after this VI and is connected by the error wire. The wierd thing is, as far as I know, this can ONLY happen if the queue is destroyed in some parallel process while this VI is waiting for an element to be enqueued. LabVIEW: Refnum became invalid while node waited for it. Here is the error:Įrror 1122 occurred at Dequeue Element in Process GUI Events.vi:34->Engine 422.vi I am getting sporatic occurances of an error with one of my queues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |