2 executables, 2 computers, 1 calls the other

[torekp]

I've got 2 computers that need to work together. The Control computer accepts user commands and displays a few indications of how the job is running. The Spec computer does the serious number crunching, and usually gets no user input at all. To keep it simple, pretend the executables are named Control.exe and Spec.exe. I would like Control.exe to start Spec.exe, but I don't know how. Once they are both running they will communicate with no problem (via reflective memory cards and optical fibers) - I've got that covered.

Right now, I've got an actual Labview VI, Spec.vi, on the Spec computer. Labview stays open on the Spec computer, and Control.exe uses VI server to open Spec.vi and run it, and that works fine. BUT - I'd rather have an executable, and not run the Labview development environment - I figure that's leaner and meaner, somehow.

One thing that occurs to me is to have a two-part Spec.exe. One very non-resource-intensive part would run all the time, and when Control.exe demands it (still using VI server?) that part would open up the main part and run that.

Better ideas welcome. I'm not very TCP-IP / .NET / etc savvy, so if you're going there, dumb it down a bit please.

[HeLo]

hi torekp,

this solution looks to me simple and lean. Another solution would be to run a Telnet server on your spec computer and start your program through that server. I implemented this about a year ago in a virtual machine in order to simulate an instrument, with which we communicated through Telnet and FTP. However, this would only be an advantage, if the Telnet server were running anyway and was eased in my case by having the Internet-Toolbox of NI available.

Herbert

[Gary Rubin]

One thing that occurs to me is to have a two-part Spec.exe. One very non-resource-intensive part would run all the time, and when Control.exe demands it (still using VI server?) that part would open up the main part and run that.

We are doing something very similar to this. Computer A is running C code. Computer B has 2 or 3 different LabView EXEs that can be run, depending on what the C code wants done. We have a very lightweight Labview EXE on Computer B that's just listening for a TCP/IP command from computer A, then launching the appropriate EXE.

TCP/IP in LabVIEW is very easy.

[Grampa_of_Oliva_n_Eden]

I've got 2 computers that need to work together. The Control computer accepts user commands and displays a few indications of how the job is running. The Spec computer does the serious number crunching, and usually gets no user input at all. To keep it simple, pretend the executables are named Control.exe and Spec.exe. I would like Control.exe to start Spec.exe, but I don't know how. Once they are both running they will communicate with no problem (via reflective memory cards and optical fibers) - I've got that covered.

Right now, I've got an actual Labview VI, Spec.vi, on the Spec computer. Labview stays open on the Spec computer, and Control.exe uses VI server to open Spec.vi and run it, and that works fine. BUT - I'd rather have an executable, and not run the Labview development environment - I figure that's leaner and meaner, somehow.

One thing that occurs to me is to have a two-part Spec.exe. One very non-resource-intensive part would run all the time, and when Control.exe demands it (still using VI server?) that part would open up the main part and run that.

Better ideas welcome. I'm not very TCP-IP / .NET / etc savvy, so if you're going there, dumb it down a bit please.

VI server works with an exe so.... what is the issue?

Ben

[vugie]

I would change the title of this topic to "2 executables, 2 computers, 1 call to rule them all"

[Grampa_of_Oliva_n_Eden]

I would change the title of this topic to "2 executables, 2 computers, 1 call to rule them all"

... and in the network bind them.

Ben

[smenjoulet]

... and in the network bind them.

Ben

Nice!

One thing that occurs to me is to have a two-part Spec.exe. One very non-resource-intensive part would run all the time, and when Control.exe demands it (still using VI server?) that part would open up the main part and run that.

Better ideas welcome. I'm not very TCP-IP / .NET / etc savvy, so if you're going there, dumb it down a bit please.

While I think the lightwieght exe approach would work great, here's another alternative for you to consider.

Look at the SysInternals tools (now a part of Microsoft), specifically PsExec.

This allows you to run processes on remote machines, provided you have the proper access of course, which I assume you would.

-Scott

[torekp]

VI server works with an exe so.... what is the issue?

But the executable on Spec already has to be running to "hear the call", does it not?

Look at the SysInternals tools (now a part of Microsoft), specifically PsExec.

That sounds interesting, I'll have a look.

Thanks everyone!

[Black Pearl]

When using VI Server over entwork, connect to the App.Instance of the other PC. I don't remember the details, but I think it was just as easy to start the LV runtime...

Felix

[Grampa_of_Oliva_n_Eden]

When using VI Server over entwork, connect to the App.Instance of the other PC. I don't remember the details, but I think it was just as easy to start the LV runtime...

Felix

Yes and you have to specify the full file paath because the VI is not in memory yet.

Ben

[Yair]

Nice!

I was thinking *groan*.

[torekp]

When using VI Server over entwork, connect to the App.Instance of the other PC. I don't remember the details, but I think it was just as easy to start the LV runtime...

Felix

I'm getting error 7. Relevant parts of my .exe's INI file:

server.tcp.servic="My Computer/VI Server"

server.tcp.enabled=True

server.tcp.acl="+localhost" [note, I also tried server.tcp.access = this]

server.tcp.port=3362

server.vi.callsEnabled=True

server.vi.propertiesEnabled=True

Block diagram of caller:

Note, I'm just testing locally for now, just to see if I can open and run a .exe The path is definitely correct; I put a "current VI path" constant on my EXE's block diagram and added an indicator.

Labview 8.5

Edited December 21, 2009 by torekp

[Ton Plomp]

I don't think you can open a VI inside an executable any more (8.2 and up) with a path.

One idea is to just load the VI into memory in the remote application (server). In the client you only use the VI name (as a string constant), one option is to get a list of all the Exported VIs running (don't know if this works for a remote app).

Also don't forget to set the Exported VIs to '*'

PS your ini says 3362 and the code says 3363)

Ton

[Grampa_of_Oliva_n_Eden]

I'm getting error 7. Relevant parts of my .exe's INI file:

server.tcp.servic="My Computer/VI Server"

server.tcp.enabled=True

server.tcp.acl="+localhost" [note, I also tried server.tcp.access = this]

server.tcp.port=3362

server.vi.callsEnabled=True

server.vi.propertiesEnabled=True

Block diagram of caller:

Note, I'm just testing locally for now, just to see if I can open and run a .exe The path is definitely correct; I put a "current VI path" constant on my EXE's block diagram and added an indicator.

Labview 8.5

With 8. and beyond this got more complicated...

it is now possible to have the same VI running in more han one process context so we have to ID the context.

Open VI >>> Owniing App >>> Project.TragetItem >>> Project >>> name should give you the name of the process your target is running in.

then use

Open Application Reference >>> Projects.Projects[] to locate the conext you found above.

Once you have the right conext, then open the VI.

It looks like you have all of the security chcks OK in you exe INI but double check those plus port number and possibly the fire-wall.

Edit

The news of not being able to do this after LV 8.2 is news to me.

Ben

Edited December 21, 2009 by neBulus

[Ton Plomp]

With 8. and beyond this got more complicated...

it is now possible to have the same VI running in more han one process context so we have to ID the context.

Open VI >>> Owniing App >>> Project.TragetItem >>> Project >>> name should give you the name of the process your target is running in.

Are you sure that in an executable multiple App Instances can run?

And TorekP where do you get 'error 7'

Ton

[Grampa_of_Oliva_n_Eden]

Are you sure that in an executable multiple App Instances can run?

And TorekP where do you get 'error 7'

Ton

NO!

Not from experience. My replies where based on how it used to work mixced with mental notes when the new technology was introduced to the Champions.

Ben

[Norm Kirchner]

FWIW, I utilize the technique of running a VI that exists within an lv_EXE's memory space in many applications.

SMenjoulet was actually one of the first people that I had seen do this elegantly. His creation was LabVIEWx or LVx.

The basic idea is that within the executable, you have 1 subVI that, at the beginning of the exe's execution, spits out an event reference and stores it internally within a shift register.

<a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/c77073a3-5a2a-48d8-bc0f-47f75f104659/2009-12-21_1231.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/c77073a3-5a2a-48d8-bc0f-47f75f104659/2009-12-21_1231.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/c77073a3-5a2a-48d8-bc0f-47f75f104659/2009-12-21_1231.png" width="536" height="356" border="0" /></a>

Register the EXE for that event

<a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/79ce3e24-5d72-400a-91fa-bc69abd9aa44/2009-12-21_1231.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/79ce3e24-5d72-400a-91fa-bc69abd9aa44/2009-12-21_1231.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/79ce3e24-5d72-400a-91fa-bc69abd9aa44/2009-12-21_1231.png" width="338" height="289" border="0" /></a>

REMOTELY (from another VI or lv_EXE) Open a reference to aforementioned EXE through VI server and call that aforementioned subVI via 'CallByRefNode' and pass in the command.

<a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/af6aaa05-302d-41cd-a94a-952c8ae82f0b/2009-12-21_1246.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/af6aaa05-302d-41cd-a94a-952c8ae82f0b/2009-12-21_1246.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/af6aaa05-302d-41cd-a94a-952c8ae82f0b/2009-12-21_1246.png" width="1024" height="598" border="0" /></a>

And at the end of the day, when you run the Remote Export, you will have fired the event within the LV_EXE along with the data you passed to it.

Is this close to what you were looking for?

Also if you're using LV 8.2, there is an issue with an ini key "TCP.ACL = ...." that will need to be copied from the LV ini into your EXE's ini. This may resolve your error 7

[torekp]

But the executable on Spec already has to be running to "hear the call", does it not?

I should clarify: I was hoping - this will sound crazy, I know - that I could have no executable at all, running on the Spec computer, and then start my executable remotely. The Microsoft utility psexec lets me do that! , so I may well use that. Or I may just stick with what I've got now - a small LV exe on the Spec computer, which periodically reads a certain file on the Spec computer. When the Control computer writes the word "start" into that file, the Spec.exe uses LV server to start Spec_Main.vi (as executable), the actual do-the-work program, which is an "always include" in the build.

[smenjoulet]

SMenjoulet was actually one of the first people that I had seen do this elegantly. His creation was LabVIEWx or LVx.

First, Norm, thanks for the kudos. This was born of a desire to have a pure G app interface/control scheme similar to ActiveX, hence the name. And no, I didn't name it, but it managed to stick. I'm not going to add anything to his post. He explains it pretty well. If you decide you want to look at this technique further and need some more guidance, I'm sure one of us will help you out.

I'm getting error 7. Relevant parts of my .exe's INI file:

...

Second, while VI server can be a bit tricky, the discussion is making it over complicated. Here is what you need in your EXE's ini to make it work:

[your ini]

Yes, that's right. Nothing. Of course that's an oversimplification, because then you have to manage the VI server settings within your application yourself (setting it enabled, setting port, setting machine access, setting VI access, etc.). The defaults will be port=3363, server=off, machine access=localhost, VI access=*. If you are at all concerned about security, that may be your best bet. If not, the following settings may be a little more reasonable:

[your ini]

server.tcp.port=xxxx

server.tcp.enabled=true

That will set your port and enable VI server. Machine access will default to localhost and VI access will default to * (all VI's accesssible)

If you want to set only specific VI's as accesible than add the line:

server.vi.access="{your VI names/patterns}"

To change machine access settings, add a line like this:

server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000" -> This is the value to give all machines access.

You can set all this in your project properties and it will be part of your ini when you build.

I should clarify: I was hoping - this will sound crazy, I know - that I could have no executable at all, running on the Spec computer, and then start my executable remotely. The Microsoft utility psexec lets me do that! , so I may well use that. Or I may just stick with what I've got now - a small LV exe on the Spec computer, which periodically reads a certain file on the Spec computer. When the Control computer writes the word "start" into that file, the Spec.exe uses LV server to start Spec_Main.vi (as executable), the actual do-the-work program, which is an "always include" in the build.

If you go with the small exe, then the technique Norm describes will work great for you. No need to periodically monitor a file. Just send a message directly to the app. Or simply just run a VI remotely to load/launch your main VI.

Also, it is possible to load/run your main VI directly into your small app (from say an llb build) to do the work if you didn't want to launch a separate exe. Lots of options...

- Scott

[Grampa_of_Oliva_n_Eden]

... Lots of options...

- Scott

Thank you Scott.

Another option inspider by a post by JPD years ago...

He wrote a VI server based ap on his work machine to transfer file he forgot at home. Invoked all of the VI's on his home machine to do the transfer...

Point is...

A similar app could copy your exe and then invoke it.

Done stirring up the mud,

Ben