Another way to programmatically open/close vi's?

[bigeeguy]

Good Morning,
    I am looking for a different way to open support VI's from a main VI. In particular, I have a main vi that handles user interface and execution. There is also an additional support VI that recieves/decodes messages from the device under test. The messages are coming rather quickly, so it is running in a fairly tight loop. I am not refering to this vi as a subvi because I see its execution at the same level as the main vi. So, what I am having trouble with is implementing a robust method of opening and closing this support VI.

I have worked up a little example to experiment with different ideas. In the example, I am using the "Run VI" method discussed in some of the forum postings. When data is ready at the support vi, it sends it to the main vi using a queue. This has gotten me part of the way to what I ideally want by decoupling the execution of the support vi from the main. There are two big problems that I see with this method.

1) The support VI needs to be reenterant in order for the "Run VI" method to work. With this set as reenterant, I am not able to debug it with break points and whatnot which is a  big issue right now.
2) If the main VI abnormally terminates, the support vi is kept running. When the main VI is reopened, it throws a stink about the subvi already being open in memory.

So is there any thing that I am missing here? Am I making this problem way harder then it needs to be? It seems to me that this should be a fairly straightforward thing to do which is why I am uncertain about my method.

[Marc_A]

I just wanted to comment about one thing I noticed right away. You shouldn't use one queue to send commands and data back and forth. If you enqueue some data in the sub vi, but the main vi doesn't dequeue it in time, your sub vi will then dequeue it to see if it's a command. You could lose data the way you're passing it back and forth. I would suggest making a separate queue for commands.

Also, the way you have this setup, you don't even have to call the sub vi dynamically. Just put the sub vi right on the block diagram and it will run exactly how you want it to. It will run in parallel with any other code you have in the main vi that does not depend on it.

[smercurio_fc]

Your statement "The support VI needs to be reenterant in order for the "Run VI" method to work" is not true. It's only true because of what you're doing. If you use the "Open VI Reference" function then you do not need to make your subVI reentrant.

I agree with creating separate queues for commands and data.

[bigeeguy]

Mark A
    I have found that in my actual application, if the vi that handles the messaging is waiting for some reason (looking for a particular message to come over the queue), the main vi hangs up. In reading other posts, it seems that other people have had the same thing occur. If its a setup thing on my part that is causing the problem, I want to get to the bottom of it.

smercurio...
    I have also tried the open VI reference method you described but was unable to get it to do what I was looking for. Do you think you could provide me with a simple example or point me to one somewhere?


I agree with both of you that my queue messaging scheme is not ideal, but I just wanted to throw something quick together in order to figure this vi opening thing out. Thank you both for responding so quickly.

[Marc_A]

Ok here's what you do. Instead of checking to see if there is something in the queue before dequeueing an element, just use the dequeue. There's a timeout input on it. Set this to 100 ms. Then wire the timed out output to a case structure. The false case will run if there was an element in the queue, the true case will run if it's empty and hasn't received any data. This is probably how you had it running when you said one of the vis hung up, you just didn't have a timeout specified.

Now, if you do it this way, you definitely need 2 queues, becuase this will dequeue an element as soon as there is data available. So if you enqueue a command or data, you don't know which vi will dequeue it. There is a race condition.

As far as calling the vi dynamically, like I said, you don't even need to. Just put a regular call to it in the main vi where you have the Run VI node now. It will start running in parallel with the rest of your code.

[smercurio_fc]

As Marc indicated, since your subVI has an internal loop all you really need to do is what he said and place the subVI in the main VI's block diagram. It will run in parallel with your main VI's code.

For a more general answer, the "Open VI Reference" does the same thing you're doing with the reference constant. All you need to do is to provide the path to the VI to get a reference. Use this function to replace your VI reference constant.

Examples are provided with the LabVIEW installation.

Message Edited by smercurio_fc on 01-24-2007 10:30 AM