Using DataSocket and Exiting an EXE

[klessm1]

Maybe some of you have ran into this and know of a fix, because I am :headbang:

I am trying to figure out how to use datasocket without having the EXE wait ten seconds before it closes. For an easy test vi I just put a control on the front panel and set it up for datasocket in the control properties (subscribe, local system). If I run the vi and exit from LabVIEW, it takes LabVIEW about ten seconds to close (same with an EXE). I have tried setting the default setting for the datasocket as disabled and then enabling it in the vi and then disabling it before I exit. Same ten seconds. I even tried just opening a datasocket up and then closing it (datasocket primitives) with the same issue.

I am using 7.1.1 right now so I can't use the Shared Variables, plus I am needing to communicate with applications in LV 5.1.1 so that wouldn't work anyway. I could add some TCP-IP drivers to accomphish the data transfer, but I wanted to see if there is an easy solution before I started down that path.

Thanks for any input.

[Michael Aivaliotis]

Maybe some of you have ran into this and know of a fix, because I am :headbang:

I am trying to figure out how to use datasocket without having the EXE wait ten seconds before it closes. For an easy test vi I just put a control on the front panel and set it up for datasocket in the control properties (subscribe, local system). If I run the vi and exit from LabVIEW, it takes LabVIEW about ten seconds to close (same with an EXE). I have tried setting the default setting for the datasocket as disabled and then enabling it in the vi and then disabling it before I exit. Same ten seconds. I even tried just opening a datasocket up and then closing it (datasocket primitives) with the same issue.

I am using 7.1.1 right now so I can't use the Shared Variables, plus I am needing to communicate with applications in LV 5.1.1 so that wouldn't work anyway. I could add some TCP-IP drivers to accomphish the data transfer, but I wanted to see if there is an easy solution before I started down that path.

Thanks for any input.

Have you tried running the close datasocket server VI?

[klessm1]

Have you tried running the close datasocket server VI?

I found that it didn't matter if the server is running or not. Attached is a vi that opens the server, the controls connect and then the server is closed and labview is exited. Note the time it takes for labview to close down on the task bar (or in task manager). On my system it takes about ten seconds. I can also remove the server open and close and it does the same thing.

Thanks

Download File:post-2966-1129240611.vi

[Neville D]

I found that it didn't matter if the server is running or not. Attached is a vi that opens the server, the controls connect and then the server is closed and labview is exited. Note the time it takes for labview to close down on the task bar (or in task manager). On my system it takes about ten seconds. I can also remove the server open and close and it does the same thing.

Thanks

I tried your VI and everything works pretty fast. Close < 1s.

Do you have enough memory in your PC?

I have a laptop with 1Gig of RAM (just for comparison).

Neville.

[klessm1]

I tried your VI and everything works pretty fast. Close < 1s.

Do you have enough memory in your PC?

I have a laptop with 1Gig of RAM (just for comparison).

Neville.

So LabVIEW disappears from the task manager in less than a second or does the vi window just close?

It removes the vi's from memory fast on my machine and closes those, but it seems like LabVIEW is trying to cleanup loose ends with the operating system after that.

I am running WinXP Pro on a Dell workstation with a 3.2GHz processor and 2Gig of RAM so memory isn't an issue. I also tried running the same vi on a Win2000 virtual PC with the same issue. I am running trend office scan virus software on both images, but I don't think that would cause a 10 second delay.

It almost seems like a timeout value. I tried the timeouts when using the primitive datasocket vi's (which didn't work), but I don't know of any timeout values built into the control datasocket properties.

UPDATE: I also tried it on a coworker's computer that is a winXP computer as well. It took the same 10 seconds to close.

[Michael Aivaliotis]

So LabVIEW disappears from the task manager in less than a second or does the vi window just close?

It removes the vi's from memory fast on my machine and closes those, but it seems like LabVIEW is trying to cleanup loose ends with the operating system after that.

So LV takes this time to close... so? What's the problem?

[Neville D]

So LabVIEW disappears from the task manager in less than a second or does the vi window just close?

It removes the vi's from memory fast on my machine and closes those, but it seems like LabVIEW is trying to cleanup loose ends with the operating system after that.

No, it looks like everything closed out pretty fast. Just a comment, publishing data (Real or booleans) is a more efficient (faster) way to go than the simple method of right-clicking on a control & publishing it to the DS server.

Neville.

[klessm1]

No, it looks like everything closed out pretty fast. Just a comment, publishing data (Real or booleans) is a more efficient (faster) way to go than the simple method of right-clicking on a control & publishing it to the DS server.

Neville.

I sent this issue to NI and they reproduced the problem I was seeing. Here is their response:

Thanks for the clarification! I was able to reproduce exactly what you are talking about and I have to admit that it is quite strange. Front Panel DataSocket connections are not supposed to be waiting for updated values at all, so there is no way to set their timeout values and timeouts should not even be coming into play, although it appears they are. You are right in that the delay has nothing to do with the VI, but actually occurs in the Run-Time Engine, which runs in parallel with the development environment. I will submit this behavior for R&D to investigate, but in the mean time, I do have a workaround for you! You can hide this Run-Time Engine (duplicate

entry) that appears in the task bar by adding the line "HideRootWindow=True" to your LabVIEW.ini file (located in the same directory as LabVIEW.exe). This will hide the window that seems to be lagging and make the issue invisible to the user. Just keep in mind that if you are building executables (which have their own .ini files), you will need to add the same tag to their .ini files to get the same behavior.

Please let me know whether you are able to successfully implement the workaround and whether it is a viable solution for the time being.

As far as your comment, do you mean that using the datasocket primitives like in the picture attached? Maybe you guys know a better way to do what I want. Here is my situation:

I am writing a test executive and operator interface that is written in 7.1.1. This test executive loads and runs about fourteen different test applications based on the product being tested. The current applications and test executive is written in 5.1.1, and uses shared globals to communicate with the test executive (test applications use globals within the test executive application). The new test executive I am creating passes data to the test application through a generic data cluster (var name, type, and data as varient) using the call by reference for applications written in 7.1.1. Since I want to only have to update the one test executive, I wanted it to run the legacy code (which will probably never be updated because of time money contraints). I also wanted to be able to upgrade in the future without effecting the test application releases, and allow applications to upgrade to new versions at their own pace. So for these applications, I use an activeX application written in the version of LabVIEW I need to run. I pass the data using the set control and get control values.

The reason I needed to use datasocket (or something else?) was that I needed to transfer some data back while the test application is running. The only thing I use the datasocket information for is the current test display which will get updated around 400 times or so during product test, and the progress bar which only gets updated after every test block.

When I run test apps in the same version that the test exec is in, then I just pass the status data back using a queue and the progress data using the control reference (since it is not updated very much). The problem was communicating this information easily across LabVIEW versions. The datasocket setup in the control seemed the easiest way to accomplish this task.

Thanks for your inputs.