LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

problems with vi server application

I have problems to get my application running and decided to ask the LABVIEW community for help. My main program should be able to run several instances of a subroutine, that I designed before as a subvi. It serves as a sort of player, allowing the user to step (fast or slowly) through one of several image stacks.
When I run this vi via server I can get only one instance at the same time, but if I press its stop button, it closes without leaving a trace. When I store it as a template (.vit) then I can get several instances of the player, but with the following undesired effects:
1) Even if I use "Make window always on top" this is true only for the last instance called (because the name string is always the same?!?)
2) The windows of all instances have to be closed manually after they have been stopped, even if the references of them were closed programmatically.

I still have another question: If several instances of the same subroutine are needed, is it not possible to use the method "Call By Reference Node" with strictly typed references? The transfer of the data from the calling vi to the player vi's would be much easier than with invoke nodes and "Flatten To String" for each control.
I hope I could explain what my problems are. Thanks in advance.
0 Kudos
Message 1 of 9
(2,649 Views)

1) Even if I use "Make window always on top" this is true only for the last instance called (because the name string is always the same?!?)


Only one window can have the "Always on Top" property. That's just the way it is.



2) The windows of all instances have to be closed manually after they have been stopped, even if the references of them were closed programmatically.


Closing a reference to a programtically open window does not close the panel. These are two separate things. Since the panel is now open, it maintains a reference to itself. You still should close the original reference you used to open the VI, but you'll have to code something into the VI itself to close it when it's stopped. HINT: HOw are you opening your templates? Maybe a property node set to "FR.Open" with a True boolean? Tryusing that same property in the VI template itself after the main application loop but set to False. There's another way using the Event Structure if you're interested.


I still have another question: If several instances of the same subroutine are needed, is it not possible to use the method "Call By Reference Node" with strictly typed references? The transfer of the data from the calling vi to the player vi's would be much easier than with invoke nodes and "Flatten To String" for each control.
I hope I could explain what my problems are. Thanks in advance.


Yes, this is a good way to do it if you have a lot of data to pass. The one thing to keep in mind is that all the subVIs you want to call with a particular node must have the same connector pattern.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 2 of 9
(2,642 Views)
Hi Ed,
thanks for your fast replay.
To 1: How can I then manage that several windows are permanently visible(as in programs like Photoshop or ImageJ). Here if I make a mouse click to somewhere the older player windows disappear and can only be detected using the window menu item of the calling routine if that was stopped.
To 2: Yes I used a property node set to "FR.Open" with a True boolean and I will try what you proposed for closing the window of the instance.
To 3: I thought that this method is not available for templates, now I will try that again.
Thank you again.
Detlef
0 Kudos
Message 3 of 9
(2,635 Views)
To answer numbers 2 and 3 together...

The Call by Reference Node does work on Templates. I just tried it and it gives a uniqely named instance of the template. To open and close the windows automatically, go into the "VI Properties>Windows Appearance" and check the two boxes "Show Front Panel When Called" and "Close afterward if originally closed". This will open the panel when it's called, and automatically close it when the VI is stopped.

As for number 1, you might try something like the attached VI. It looks at all VI in memory and checks to see if one is frontmost. This name array should be filtered to just look at the spawned templates you've opened. If none of them are frontmost, it makes the first one in the array frontmost. This would at least always keep one on top. You could just run this as a separate loop in your main application.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 4 of 9
(2,632 Views)
Regarding having windows like in photoshop or word, this is more complicated, but have a look here for a start.

___________________
Try to take over the world!
0 Kudos
Message 5 of 9
(2,625 Views)
Hi Ed,
it seems to me that the method " checking the two boxes "Show Front Panel When Called" and "Close afterward if originally closed" does not work if using templates. I have tested it using the example given by Koninika (National Instruments): parallel.zip (see http://forums.ni.com/ni/board/message?board.id=170&message.id=74443&requireLogin=False)
All works fine until you change VI1 to a template. Then again one has to close the window of every instance by hand when it was stopped running . But now I have found a solution: The "run" routine (using FP.Open and Run VI) in addition determines the unique name given for that instance (eg. "sub1 35.vi") and transfers this name to the instance of VI1 just started. This instance is now able to at least hide itself (with LVUTIL routine "hide window") when its stop button is pressed.
Best regards
Detlef
0 Kudos
Message 6 of 9
(2,620 Views)
If you're opening the Templates via VI server, the open reference to the VI may be preventing it from "finishing" properly. Perhaps LV won't unload the code until you free up the reference. Try closing the reference before the Template VI is finished and see if it closes then.

AFAIK the templates SHOULD close themselves after completing their work....

Hope this helps

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 7 of 9
(2,614 Views)
DOH!!!

Using the "Call by Reference" node isn't going to work for opening multiple instances of the template because the node works the same way a subVI does. That is it will stop the calling VI until the called VI template stops executing and returns control to its caller. Two of VIs in the attached zip file show this. Save them to the same directory and open and run the "Caller.vi". An instance of the "firstrun.vit' will open, and will close itself when you hit the Stop button. But, the "caller.vi" will sit and wait for the firstrun instance to stop. So that's not going to work for you.

The other two VIs in the zip (caller1.vi and firstrun1.vit) will work for you. I changed the caller to use the FP.Open property and the Run method to open instances of the template. Some code was added to the template to properly stop and close it. Since this is a template that has not yet been saved, you have to implicitly open a reference to itself in the template before you try to close it front panel or it will prompt you to save changes.

Just hiding the window will all sorts of refernces open and could cause memory problems if you have a lot of them. I also changed one of the Window Appearance properties to "Float". This is similar to "Modal" except that it does not lock out use of other windows. It keeps it on top but it can lose focus. This way these spawned windows will not get hidden.

Hope this works for you.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 8 of 9
(2,613 Views)
Hi Ed,
I was in holiday for one week, so I tested your solution just now. It works fine, thank you very much.
Detlef
0 Kudos
Message 9 of 9
(2,588 Views)