Can I find the OS of a remote system using LabVIEW?

[Michael.Johnson]

I wish to be able to start an application on a remote system using LabVIEW. To do this, I need to know what the OS of the remote system is (Windows, Linux, etc). I can ask the user to provide this information for me, but is there any way I can get LabVIEW to automatically retrieve this information? I know I can use the application node with the OS sub-section to get this information for the local machine... is there any way I can remotely run this? Would VI server allow me to run this, if I turned it into a VI, on the remote system such that I could retrieve this information for the remote system? Or is there a neater solution I'm missing?

Cheers,

M.J.

[tst]

You can use the VI server to get this data from a VI running on a remote machine (just look at the help for Open Application Reference), but the thing is you will have the LV run-time engine installed there for the VI to run. Other than that, I don't think there is any other way, because I'm fairly sure TCP (assuming that's what you're using) doesn't include OS information. I think you will need to have LV for each OS in order to compile the VI.

If you're already doing this, you can have the System Exec VI start the application locally, and you will just need to call the VI and pass the right data into it.

[Michael.Johnson]

OK, What if I have the run-time engine installed on the remote system, but I want to just run the VI remotely once? So, for example, I get the required information from the user on the local system, I then want to start/run another VI on the remote system (where LabVIEW is not necessarily already running, and/or the required VI is not already loaded) using this information, such that it will run up this 3rd party application on my remote system (using the system exec vi, for example). Is this possible? Or is there some other way of doing this?

Cheers,

M.J.

[tst]

I don't think that's possible.

According to the help on Open App Reference, it only works on running instances of LV, so to start running the VI, you will need to get the local OS to run it itself, but for that you have to know which OS it is and that's exactly what your VI is supposed to find out and so on.

I think your only option is to have the VI open all the time. It can be completely hidden from the user using the VI properties settings.

[Henrik_Volkers]

Wouldn't it be a solution to have a small vi-launcher.vi autostart running in the background? (Mothers little helper   )

 The vi-launcher.vi could be controlled with the vi-server and should be able to start whatever vi he could reach (even on a network drive).

[tst]

That was my basic suggestion. The thing is that he wants the VI to run only once, and I don't think that's possible because to do that, you have to run it using the local OS.

[Michael.Johnson]

Heya... many thanks for the suggestion(s).

The problem with my case is there's any number of users on the network that might be using this, and it could be running on a Windows or Linux box, depending on user circumstances, so trying to get a VI Starter type application put into the start-up of all machines just in case is a) overkill & b) more than I want to bite off 😉 So basically I need to have the VI running on the machine in order to use VI server is what I'm hearing & reading from the help, which essentially my idea of dynamically firing off labview & loading/running any VI on the remote system just ain't possible... hmmmn.

Back to the drawing board then, it looks like...

Cheers,

M.J.

[shoneill]

Of course you could simply have a static IP assignment saved in a text file saying

100.100.100.1 is WinXP
100.100.100.2 is Linux
100.100.100.3 is Mac OSX

and so on.

OK, this is static and relies on the list being up-to.date, but if the machines don't change much (or aren't dual-boot configured) then is will probably suffice.

Shane.

[unclebump]

Could you put a text file on each computer with the same filename?? Have labview read the OS from the text file. I don't know how many computers you need to be using.

[unclebump]

Try to read the %OS% environment variable.