SOS! Traped in a while loop, need to stop VI right now without quiting LabVIEW

[tst]

---

@Troy K wrote:

The only problem is that it won't jump in front of a modal window

---

That's why you build it into an executable. That way it's another process.

[BryanL]

Thanks to tst and Troy for the Task Managers. I cant try Troy's as I am running LV7.1.  I tried tst's with an empty string wired to the machine name. It worked nicely. I guess if I build it into an executable then I need to wire localhost to the machine name.  Without building this executable, I decided to run my while loop vi and test tst's Task Manager, I got into trouble again, as this time the while loop vi blocked the Task Manager. So I tried Troy's and Altenbach's tricks try to stop the while loop vi, I end up having the Task Manager getting infront of the while loop panel which didnt have the correct string wired to its machine name in the block diagram (i.e. not executable), and I cant stop either vi.  But this time I dont have any unsaved work, so I can exit LV.  My main mistake was having that pop up window in the while loop, so I got double trouble.

I am going to build an executable from Troy's Task Manager, then I should be safe. My hard learned lesson here is that nested while loops and pop up windows are truly bad combinations if you dont know the nested while loop behavior to start with.  Thanks again for sharing the task managers!

[BryanL]

Still got some problem with Troy's Task manager...I first built the executable with "localhost", it didnt detect any running VI including itself.  Then I used an empty string wired to the machine name and rebuild the executable, the task manager is only detecting itself, not the running whileloop.vi.  I must have missed something?

By the way I am using Aldenbach's trick in terminating the whileloop.vi. It worked very nicely and reliably.

[TroyK]

Try getting rid of the "Open Application Reference" before the "Application:All VIs In Memory" property node. I don't think you don't need it for the local machine. (Although I don't have an application builder here right now to test it.)

[tst]

You must have the Open App Reference. Once you build it, it becomes a seperate application (with a single VI, as you saw). To connect to running instance of LabVIEW, you have to do an Open Application Reference with Localhost (since you're on the local machine) and, equally important, with the right port number.

The default number is 3363, but to get it to work you need a couple of extra steps:

• You have to go into the LabVIEW options and enable the VI server's TCP access on that port. If you don't do that, you won't be able to connect to LV.
• You will probably need to do the same in the exe, but set a different port number, since I'm pretty sure that by default, the application will connect to itself if both it and LV have the same port number.
• I'm fairly certain that when you run it for the first time like this, you will get a warning from the firewall. You need to unblock the application so that it can communicate with LV through TCP (if you're using the Windows firewall it's simply a matter of clicking Unblock in the dialog you get).

Once you set it up, it should work perfectly and forever. You should note, however, that was just a quick example. I would polish it up greatly if I were using it myself (which is probably not a bad idea, now that I think about it).

[falkpl]

Yes building a task manager for labview is not hard and I have one myself (unfortunately company property) but I still dont know why there is not one built into labview saving us from reinventing the wheel.  It would take their developers less than a day to do but would save thousands of hours for the users of labview.

Paul

[BryanL]

Hi tst, since we are running the task manager on the local machine, how can we still need to use TCP and disable the firewall? I thought LV shall be able to do all this locally without involving any ports. Will this cause any security concern if the firewall is disabled and TCP port enabled? 

Running your task manager as a VI (i.e. without building an executable) is already helping me a couple of days ago on another machine where I had a similar problem, i.e. one of the vi got frozen. By using the task manager, it really made things convenient. The task manager is very nice to have on a developer's desktop.

[TroyK]

I can understand why tst suggested to compile it to an exe. It needs to be running as a different process to get in front of a modal window such as the prompt in your original while loop vi you posted in the first message in this thtread.

Then because it is an exe and a different process, it needs another way to access the uncompiled vi(s) running. (At least that is how I understand it.)

You do not need to disable your firewall, you just need to allow the VI TaskManager app to access the TCP port you assign for it through your firewall if it kicks up a stink.

Message Edited by Troy K on 07-02-2007 03:15 PM

Message Edited by Troy K on 07-02-2007 03:16 PM

[TCPlomp]

---

@BryanL wrote:

Hi tst, since we are running the task manager on the local machine, how can we still need to use TCP and disable the firewall? I thought LV shall be able to do all this locally without involving any ports. Will this cause any security concern if the firewall is disabled and TCP port enabled? 

---

Port filtering!

Only allow the port that LabVIEW uses to be open (and than only for localhosts.

Another possibility is ActiveX, LabVIEW exposes it's VI server model as an ActiveX server. That can be accessed with LabVIEW (or any dev envirenment including Excel/word), and you shouldn't miss anything, it just sounds like a detour.

Ton

[tst]

---

@TonP wrote:

Another possibility is ActiveX, LabVIEW exposes it's VI server model as an ActiveX server. That can be accessed with LabVIEW (or any dev envirenment including Excel/word), and you shouldn't miss anything, it just sounds like a detour.

---

It used to be limited, but I believe it should have the VI methods in any case. The main reason I don't like this is that it's Windows specific. Using the VI server should work transparently across networks and platforms.

Bryan, as Troy suggested, when it's a sepaerate process (which is a good thing) it needs some way to talk to the LabVIEW process. This is done through TCP even in the local computer (the communication packets doesn't actually leave the local computer). As said, you don't need to disable the firewall, just to allow the task manager to talk on the port it wants (and to enable the VI server's TCP access in LV).