TestStand + VI Server

[Thang Nguyen]

Hi everyone,

I am working on a project which require communication between TestStand and multiple LabVIEW executable programs. This project is used for testing the operating of a system which involved different type of controller which is simulated by independent software-in-the-loop or hardware-in-the-loop LabVIEW programs. So far we discussed that the TestStand will be run on a PC which communicated with other PCs which run seperated simulator by ethernet. Each of this simulator are distribution version which is installed as executable on each system, it's not in the developement evironment. I am trying to figure out how to from TestStand I can access and change value of the controls on the GUI of each simulator the set the value as well as read the value as feedback. For this requirement I think about using VI server solution which is get the reference of the controls on the simulator.

After doing some experience examples, I found some issues

I post here my first question:

I tried with some examples in articles on NI web site.

This is one example:

Controlling Two Executables with the VI Server

http://zone.ni.com/devzone/cda/epd/p/id/1366

In the example the Master .vi try to get the reference from the Slave.vi which stored in the same location with the exe file. This is inrealistic with the distribution version where the installation files are not located in the same location with source files.

I still cannot find an example which point directly to an executable file, not the vi file and get the reference to the controls on the panel. If you know any information about this, please let me know.

Best regards,

Thang Nguyen

[Dan DeFriese]

I still cannot find an example which point directly to an executable file, not the vi file and get the reference to the controls on the panel. If you know any information about this, please let me know.

The trick here is that your not pointing to an executable, You want to connect to the machine/IP Address and port (e.g 3363) on which the executable's VI Server Instance is listening. Also you have to make sure that the executable INI file is setup to start the VI Server.

Well, I'm having trouble uploading my attachment, but just look into the Open Application Reference and Open VI Reference primitives. I found this very easy to glue together when I did it. If I get a chance, I'll post an example of how I did it.

[Thang Nguyen]

You can upload a screenshot in which describe how you can start get the reference to the machine/IP and the executable file. Sure the example will help me more ^_^

Best regards,

Thang Nguyen

[Dan DeFriese]

In my project I use localhost since the executable resides on the same machine

Open Application Reference with say IP=192.168.1.27 and Port=3364. (The IP is the remote machine and the Port the identified in the INI file.)

Open VI Reference is the Top Level VI "EUIOHost.vi" with which I want to interact.

I pass both references back to TestStand where they're placed in a Global. Each test uses the VI Ref to obtain Control Ref's and manipulate as needed. I made several wrapper VIs which I keep in the VI Server subfolder. I thought it worked out pretty neat for my first/last TestStand project.

Hope this helps.

[Thang Nguyen]

Thank you so much,

I have question:

Open VI Reference is the Top Level VI "EUIOHost.vi" with which I want to interact.

What happens if all my simulators are installation version, which are .exe files?

Or should I copy the source files to the install folder???

Edited September 24, 2009 by Thang Nguyen

[Dan DeFriese]

Good that you brought that up... the LV versionsused in your TestStand Sequence must be the same version as used to build the EXE. Definately something to be aware of and consider before heading down this path. My approach was to build the sequence/TestStand package and VI Server controlled executable during the same process and release them on the same media. In your case, this would also imply 2 installers. One for your TestStand Machine and another for your remote instrumentation computers.

Edited September 24, 2009 by Dan DeFriese