reference to run time on network

[sgonzo]

I have a LAN with 2 computers.  1 computer has Labview 2009 environment, the other has 2009 run time engine.

I start an executable on the run time machine.  How can I get a reference to that running application from the Labview 2009 devlopment machine?

I would like to start and stop the EXE on the run time machine from the development machine.

The run time machine is listed under VI Server options, and the app name is listed under VI Server options exported apps.

When I tried to get a reference to the run time application (it is running) with machine name I get error 63.  When I try to get a reference to the run time application (it is running) with ip address, I get error 63 also.

I feel there is something fundamental I don't understand, and emails with support have pointed me only to Knowledgebase article which I have already read and tried.

Thanks for any insight.  My goal is to start and stop the exe remotely using a VI if it is possible.

[Ben]

---

@sgonzo wrote:

I have a LAN with 2 computers.  1 computer has Labview 2009 environment, the other has 2009 run time engine.

I start an executable on the run time machine.  How can I get a reference to that running application from the Labview 2009 devlopment machine?

I would like to start and stop the EXE on the run time machine from the development machine.

The run time machine is listed under VI Server options, and the app name is listed under VI Server options exported apps.

When I tried to get a reference to the run time application (it is running) with machine name I get error 63.  When I try to get a reference to the run time application (it is running) with ip address, I get error 63 also.

I feel there is something fundamental I don't understand, and emails with support have pointed me only to Knowledgebase article which I have already read and tried.

Thanks for any insight.  My goal is to start and stop the exe remotely using a VI if it is possible.

---

Sounds like you hve tried to get it right.

I have seen issue with the required tokens that allow access were not copied to the ini file of the target app. You can check this by first making usre you have the VI marked as served etc and then look at the LabVIEW.ini in the LV folder. There are more than one token but they have names and value sthat match-up with the config screens.

make sure all of those are present in the ini of you exe.

Double check the Firewall settings.

Look at the system logs etc for more clues that may help.

Ben

[sgonzo]

Thanks for the encouragement.  I may just be stuck, as there was a 2009 update that fixed a lot of problems, but it is no longer available.  My Labview rep says my option is to upgrade to 2011, so I'm trying to talk my boss into spending the money.

I added some tags to the ini I found at this link:  http://forums.ni.com/t5/LabVIEW/NI-LabVIEW-Run-Time-Engine-TCP-IP/m-p/884835/highlight/true#M399986

server.tcp.enabled=True
server.tcp.access="+localhost"
server.tcp.port=3362

but no difference.

I'm also on different OS between the machines (xp and windows 7) so I'll move my development to another machine with the same OS and retry. 

[mikeporter]

One more thing to try, go to the TCPIP setups and make sure the computer access is set to * (that means all). If not set it that way and exit LV. Now go to the LV INI file and look for a line that starts:  server.tcp.acl=

Copy the whole line and paste it into the INI file of the other LV instance, save the edited file, restart both copies of LV and retry.

I ran into this exact same problem a couple years ago when I was sharing a cubical wall with Ben. Never got a good answer from NI as to what that magic string is or why the extra copying was necessary, but it got the connection working. It may not help, but it's worth a try.

Mike...

[Ben · Accepted solution]

---

@mikeporter wrote:

One more thing to try, go to the TCPIP setups and make sure the computer access is set to * (that means all). If not set it that way and exit LV. Now go to the LV INI file and look for a line that starts:  server.tcp.acl=

Copy the whole line and paste it into the INI file of the other LV instance, save the edited file, restart both copies of LV and retry.

I ran into this exact same problem a couple years ago when I was sharing a cubical wall with Ben. Never got a good answer from NI as to what that magic string is or why the extra copying was necessary, but it got the connection working. It may not help, but it's worth a try.

Mike...

---

Thanks Mike.

Yes there should be a long cryptic string. make sure you have it in the ini used by the target.

Ben

[mikeporter]

Check this link.

Mike...

[sgonzo]

You are geniuses!  For the first time, I got a reference from open application reference.  Wired that to a property node, and got the correct app directory.

I've probably tried the same thing with the same inputs a hundred times with errors.

My boss was getting mad about how long it was taking me to figure this out.  I think I can attribute my continued employment directly to your assistance.  Only a slight exaggeration, so thank you very much for your help!!!

[Ben]

---

@sgonzo wrote:

You are geniuses!  For the first time, I got a reference from open application reference.  Wired that to a property node, and got the correct app directory.

I've probably tried the same thing with the same inputs a hundred times with errors.

My boss was getting mad about how long it was taking me to figure this out.  I think I can attribute my continued employment directly to your assistance.  Only a slight exaggeration, so thank you very much for your help!!!

---

I'm glad to hear you are still employed. Don't bother thanking me, "pay it forward" when you get a chance.

Have fun!

Ben