Jump to content

srh

Members
  • Posts

    3
  • Joined

  • Last visited

    Never

srh's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi PJM, Thanks for your suggestions! Unfortuantely I do need to access the subVIs in parallel. Call by Reference was my first choice of spawning the subVIs based on how the complexity of the information I needed to pass through to each subvi (thank you OpenG for solving most of my problems there!). A little background on my project : basically I have multiple stations that have to control multiple instruments. The template gives access to each individual station while the reentrant subvis control all the individual instruments. Each instrument (hence subvi) has a value change which needs to go to two seperate places - [1] printed to a file and [2] to a control on the template front panel. Since all the values from every instrument needed to be printed to a file, that was easy to solve with an LV2 global which stores the queue refnum. Now I need a global that is specific to each template. Unfortuantely a global is exactly that - global! I found a solution from a previous post from mgunning which I thought would work. Basically he suggests making an LV2 global reentrant and opening it from a VI server. I did a quick example of it using numbers instead of a queue refnum to see if it would work the way I was hoping and it seems to do the job. Each instance of the global held values specific to each template and was fed it's data by a reentrant subvi, but when I implemented it with queue refnums and my monster of a program, it seems to fail (again, it is fine when I ran it in non-reentrant mode). It's probably a little error I made, but given everything is setup as dynamic and reentrant, my debugging abilities are severly limited. I'm almost ready to give up and delve into the world of GOOP like Jim originally suggested. It sounds like Jim's GOOP suggestion runs similar to the example posted above, except he allows himself one more way to kill the instance if other methods fail to do so. Perhaps I read it wrong though. I'll know once I try to implement it. My worry now is that not even GOOP can help me.
  2. Thank for your help Jim.. I would LOVE to set up some debugging in the reentrant subvi to find out where the problem lies, but because I am invoking the "Run VI" method, I am left with using references which apparently still leaves me hanging. I looked through the slide package and, other than offering a small reassurance that I'm not doing anything illegal, it didn't offer any additional information I didn't already know (however, it did say queues were "useful when a process does not have a user interface AND contains a looping structure" -- that's me, right there!). As for the GOOP solution of spawning a process, that seems a little advance for the problem I am trying to solve. Especially considering I am new, I would like to try and avoid diving into that realm right now if I can help it. Actually, I'm not sure if debugging would help much. Everything works fine when I remove the reentrancy from the subvi. The problem only shows up when make it reentrant. I know the dynamic reentrant VIs are created correctly because I store the references in an array used throughout the program which I watch through probes. The references are created and, some time later, destroy automagically - which makes sense because the timed loop inside the reentrant subvi would have completed and the auto ref disposal would have kicked in. I'm sure it has something to do with the queue implementation. Is there something I'm missing about reentrant VIs? Can a dynamically created reentrant VI use a queue created by a top-level VI? And if not, how do these VIs pass information back to the main VI?
  3. Hi all, I'm hoping you can help me. I have a main top-level VI (in the form of a template so it can be opened multiple times) which must execute one VI several times, so I made that VI reentrant. I need to both send and retrieve information back from that VI. I call this VI by invoking the "Run VI" method and I can easily send information to it by using "Send Control (varient)", but my problem comes when I try to retrieve information from it. I know I can't use "Get Control (varient)" because all it would send back is a blank control (since the front panel on a reentrant vi is always blank). I thought my best option would be setting up a queue, but I tried creating a queue on the top-level VI and sending the queue name through to the VI, but it still doesn't work. I know everytime it tries to "obtain" the queue, it is creating a new one reference, but I'm not sure if this is part of the problem or not. Am I creating two queue with the same name? Is that possible? I was hoping it would be as simple as creating the queue in the top-level vi before entering a while loop, filling the queue in a timed loop in the reentrant VIs and dequeuing the elements in the top-level vi loop, but that doesn't seem to be the case. Am I doing something wrong? I'm assuming it is possible to grab information from a reentrant VI, right? I know a global would work perfectly here, but then information from the different template instances would end up overwriting or mising together. Plus I know that globals in Labview, in general, are bad. I would like to code this application as clean as possible (and being new to Labview coming from my C++ background is actually a little difficult for me! ) Sorry if this seems like a junior problem, but I really don't know how to get around it. Oops - last minute information - I am using Labview 7.1, but I am currently upgrading to Labview 8.0 (literally actually, my computer is upgrading as I type!). I'm not sure if they have added anything new to help me, but I'm assuming not, but if so, let me know. I won't have much time to play and explore with unfortunately (deadlines!!). Thanks so much in advance for any help you can provide me!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.