Trying to be lazy: using vi server between applications

[Nickster]

Hi,

I've written several small applications for controlling and monitoring various instruments.  I would love to control and communicate with these various applications (and their respective instruments) through a separate ("main") application that ties them all together.  Ideally, I'd like to be able to move each executable and its instrument to any computer in the lab and still have it function with the main application.

Can VI Server and Remote Panel control do the trick?  Some of the literature out there would have me believe so.  (See, for example, this KnowledgeBase).  I like to think that I could use a remote panel to access a temperature controller on another machine as if it were a dialog in the main application.  Then I imagine using the VI server to call some functions of the remote application in order to get the current temperature as part of a routine in the main app.  However, I've had absolutely NO luck implementing either VI Server or Remote Panel - whether between two apps or between a VI and an app, regardless of whether or not they reside on the same machine.

I've turned off firewalls, edited ini files, relaxed security settings, built and re-built applications, and lost some hair along the way...  and I have nothing to show for it.  Can  anyone help?

If VI server/Remote panel is not the way to go, then do you have any suggestions?  My next inclination is to write a minimal TCP layer or something to accomplish my goals.  But that's, like, work.

Nick

Message Edited by Nickster on 05-15-2006 08:36 PM

[TiTou]

Hi,

I've seen this "remote panel" thing and also lost a bunch of hair trying to set it up.



What I now do is using what I call a "letter box", my different application are running on RT PXI and the control PC (windows based) has an interface (tab) for each target ; in each tab I display measures from the RT targets and have the possibility to send commands. To achieve, the main PC application dynamically call a FGV vis that are running on the RT target. I have on FGV for each  RT target. The main PC reads measures from the target on the FGV and can send "orders" also ; the RT target keeps writing itsmeasures in the FGV at a constant rate and also perdiodically check if a new "order" came from the main PC.

This certainly not optimal but at least it works and I understand what I'm doing, at least I feel I do

Hope this can inspire you 😉

[becktho]

Just to throw it in: Datasocket connections

Maybe also a way to go.

[Nickster]

TiTou,

Would it be too much work for you to show me some code where you dynamically call VIs that belong to the application on the remote machine?  This is at least half of what I wish to do.  The KnowledgeBase I linked to attempted to show how to do something similar (get indicator values), but I never got it to work... Even when I re-built the example application in LV8.

Nick

---

TiTou wrote: Hi, I've seen this "remote panel" thing and also lost a bunch of hair trying to set it up. What I now do is using what I call a "letter box", my different application are running on RT PXI and the control PC (windows based) has an interface (tab) for each target ; in each tab I display measures from the RT targets and have the possibility to send commands. To achieve, the main PC application dynamically call a FGV vis that are running on the RT target. I have on FGV for each  RT target. The main PC reads measures from the target on the FGV and can send "orders" also ; the RT target keeps writing itsmeasures in the FGV at a constant rate and also perdiodically check if a new "order" came from the main PC. This certainly not optimal but at least it works and I understand what I'm doing, at least I feel I do Hope this can inspire you ;)

---

[TiTou]

Oh... well... I surely won't have time draw and upload an example before this week end... I'm quite busy these weeks

But.. ... if you're using LV 8 it should be quite straight forward, no ? I haven't used LV8 yet, but from what I read/saw/heard, it has built in tools to deploy application over a network ?
Or maybe the NI marketing&communication was too good 😄 !

I'll keep in mind your request 😉

[Nickster]

OK, it's not much but I've gotten somewhere.  This example shows one thing I've been doing wrong.  When using VI server to access VIs in a LV application, you need to specify the path to the VI in the Open VI Reference node as C:\...\application.exe\subvi.vi.  As far as I could tell, this is not found anywhere in the LV documentation on using VI server.  Strange but true.  Doing this has allowed me to use VI server between two applications on the same machine.  However, I'm still having no luck with communicating between machines.  There I can't even get past the Open Application Reference node.  I always run into error 63: " The network connection was refused by the server".  I've double checked TCP permissions and the port number on the remote server.  I've also disabled firewalls on both machines.  I don't know what else to do. 

As for accessing a remote panel of one application through another application, I still haven't made any progress.  There I always get error 1352: " Requested VI is not loaded into memory on the server computer."  I suspect I just have the VI path wrong on the RP.Open Connection To Server invoke node.  But I have tried all sorts of combinations.  Maybe I just haven't hit the right one, but nothing's worked so far.

Can anyone guide me in the right direction?

Nick

[Tyler]

One thing that you need to keep in mind when trying to open a VI using VI server is that an instance of the run-time engine needs to running. This means that if you have a fake exe that does nothing it will load the run-time engine and then you can use VI server from the host to open the VI on the remote. If you can't do this then you will need to build an exe with the ActiveX server enabled. Then you can make ActiveX calls to the exe itself to run the program. Let us know what you want to do exactly... is it an exe that you want to control on a remote machine or a VI? These are details that we need to know so that we can help you pick the best solution. Thanks.

Tyler H.

National Instruments

[Nickster]

Thanks Tyler,

I'm interested in controlling both exe's (remote panel) and their subVIs (VI server).  I think I'm finally on my way to accomplishing this. For some reason my executables weren't enabling the VI server or the web server - even though I thought I was accomplishing this by configuring VI server settings in "Tools: Options..." before building.  I discovered and corrected this thanks to Brian Renken's excellent ini file settings page. The error messages from LabVIEW actually hindered tracking down this problem. I was getting things like "The network connection was refused by the server," which in my mind implied that the server was up and running and actively rejecting my attempts to connect. In reality it wasn't even turned on. 

As for error 1352, I must have been doing something weird at the time.  Probably feeding bad VI strings to the RP.Open Connection To Server node.  Lately I've been sure to have the exe (and thus the RTE) running on the remote computer whenever I attempt to access it.  The desired VIs are loaded into memory.

While I've got remote panels figured out, I'm still having trouble using VI server to call VIs that belong to an application running on a remote machine.  Lately I'm at a point where I'm stuck with error 66: "The network connection was closed by the peer."  I added a couple lines to the ini file to enable logging on the remote TCP server.  The log file shows my computer attempting to connect but encountering error 1032: "VI Server access denied."  There is a KnowledgeBase pertaining to these errors, but I have looked over the possible problems it lists, and I don't think it's any of those.

Nick

---

@Tyler wrote:

One thing that you need to keep in mind when trying to open a VI using VI server is that an instance of the run-time engine needs to running. This means that if you have a fake exe that does nothing it will load the run-time engine and then you can use VI server from the host to open the VI on the remote. If you can't do this then you will need to build an exe with the ActiveX server enabled. Then you can make ActiveX calls to the exe itself to run the program. Let us know what you want to do exactly... is it an exe that you want to control on a remote machine or a VI? These are details that we need to know so that we can help you pick the best solution. Thanks.

Tyler H.

National Instruments

---

[pincpanter]

This may be a silly question, but... have you added the vi's you want to execute remotely to the Server Access List?
If your server is an executable, you must do it in the exe ini file or by code.
A similar consideration apply to the Server TCP Access List.

Paolo

[Nickster]

Thanks for the response, Paolo.

Here's the dumb little test application I made, complete with ini file.  You can see that I have explicitly enabled the web and TCP servers.  The VI and TCP access lists are wide open ("+*").  Maybe I have a sinister syntax error somewhere?

I've been running DateTimeRecServer.exe on a network machine with the RTE.    Then I try to call GenerateDateTime.vi from the remote exe using CallGenerateDateTime.vi.  Note that I've enabled TCP server logging in the ini file.  You'll want to change the log path to something that makes sense with your computer.  If you get to the point where I'm stuck, you'll receive error 66 from CallGenerateDateTime.vi and you'll see error 1032 in the log file of the exe on the remote computer.

Nick

---

@pincpanter wrote:
This may be a silly question, but... have you added the vi's you want to execute remotely to the Server Access List?
If your server is an executable, you must do it in the exe ini file or by code.
A similar consideration apply to the Server TCP Access List.

Paolo

---

Message Edited by Nickster on 05-18-2006 10:23 AM