LabVIEW server

Hi.
I have a project to use LabVIEW as a server to do many tasks. What i want is:
LabView receive remote data from internet about a ECG.
LabView will also run an MatLab/Octave script to analysis the data.
This data will be available from remote access (internet).
This site need to have a basic username/password.
In this site, you can see all the ECG data from each pacient and also make a full analysis from all pacients (a basic statistically analysis about all the date).
I know its a complex task, but i just want to know what i have to study and see to do it. Is it possible to do just in LabView or i will need another software? What i should look more, what you reccommend?
I dont know if it will help to understand what i want, but i did a fast abstract at paint. Thanks!
Solved!
Go to Solution.
Attachments:
derp.jpg ‏40 KB

Dunno,
Here is an example project containing a web service that follows a similar pattern as the one you described:
1. A client uploads one or more TDMS files to Receive Data.vi by using a standard HTTP multipart/form-data post to http://<server>:8080/ECGDataProcessor/data
2. The waveform data is transferred to the Data Processor auxiliary VI for processing
3. A client retrieves the processed data using a standard HTTP get to http://<server>:8080/ECGDataProcessor/data
Your client could be, for example, a static HTML page or a VI using the HTTP client. To support log in, you will either need to use the HTTP client VIs with a user name and password, or write your own logic inside of the Access Data and Receive Data web method VIs. You can find more information in the LabVIEW help topic "Configuring Web Services Security". The included project already has configured GetECGData and SetECGData permissions.
Attachments:
Remote Data Access.zip ‏83 KB

Similar Messages

  • Lost ActiveX connection with LabVIEW server

    I have called LabVIEW in TestStand and tried to execute the test cases .
    While executing I got the following error:  ( Lost ActiveX connection with LabVIEW server.
    The LabVIEW adapter will try to reconnect on the next execution attempt.-18001; An error occurred accessing the LabVIEW ActiveX automation server.).

    Same error.  Is anyone from NI going to bother commenting on this?  It's been >8 months...

  • Change TS Labview Server from Labview OI?

    I have tried the NI recommended way to select the LabView server programatically from TestStand which works fine e.g.
     RunState.Engine.GetAdapterByKeyName("G Flexible VI Adapter").AsLabVIEWAdapter.SetServerInfo(LabVIEWServer_RTEServer, "C:\\Program Files\\National Instruments\\Shared\\LabVIEW Run-Time\\8.6\\lvrt.dll")
    But I would like to call the same functionality from a LabView Operator Interface...
    After I get the engine reference I can use an Invoke node for GetAdapterByKeyname but I am struggling with the next AsLabVIEWAdapter.SetServerInfo part - I can't see these methods. Any tips/examples how to do this?
    Thanks.

    Simon,
    Thank you for providing CIM1 with this VI! I have made a few improvements to the VI and attached it below. You don't actually have to use the Adapter.AsPropertyObject method at all, you can directly connect the Adapter reference to the Variant to Data VI and cast it to a LabVIEW Adapter.
    Also, the logic that was used for determing the type of LabVIEW Server seems incorrect. According to the LabVIEWServerTypes Enumeration Help, the LabVIEWServer_ExecServer enum should be used for the LabVIEW development environment or a LabVIEW executable that registers itself as a LabVIEW ActiveX Automation Server. The LabVIEWServer_RTEServer enum should only be used for the LabVIEW Run-Time Engine. In your code it seemed like you were setting the LabVIEWServer_RTEServer enum for both the LabVIEW Run-Time Engine as well as a LabVIEW executable server. I've modified this portion of the VI as well to behave correctly.
    Let me know if you have any questions.
    Manooch H.
    National Instruments
    Attachments:
    ConfigureLabVIEWAdapter.vi ‏13 KB

  • Labview Server Use - Clusters are not compatibel

    Hello,
    I am very new to Labview and try to get an Arduino Interface running. I want to control the bias voltage of a diode and the temperature at the same time. Therefore I make use of tabcontrol and Labview Server VI to let both SubVi s run at the same time. However in order to get the refnums of cluster I have a  problem. What I did is, I created the refnums from the arduino in and error in and build them into my subvi (arduino execute). I did it that way with all the other refnums. But when it comes to the clusters of error in/out and arduino ressource in/out I get the error-
    These cannot be wired together because their data types (numeric, string, array, cluster, etc.) do not match. Show the Context Help window to see what data type is required.
    The type of the source is Cluster Refnum
        typedef 'Arduino Resource.ctl'
        cluster of 4 elements.
    The type of the sink is typedef 'Arduino Resource.ctl'
    cluster of 4 elements.
    ...any clue why this comes up`?
    I gonna attach mz Vis
    Any help is very much appreciated!
    Thanks,
    Chris
    Attachments:
    Teststand_V6.vi ‏47 KB
    call Arduino2.vi ‏742 KB
    DAC8574 SubVI.vi ‏2013 KB

    Chris123451 wrote:
    Hello,
    I am very new to Labview and try to get an Arduino Interface running. I want to control the bias voltage of a diode and the temperature at the same time. Therefore I make use of tabcontrol and Labview Server VI to let both SubVi s run at the same time. However in order to get the refnums of cluster I have a  problem. What I did is, I created the refnums from the arduino in and error in and build them into my subvi (arduino execute). I did it that way with all the other refnums. But when it comes to the clusters of error in/out and arduino ressource in/out I get the error-
    These cannot be wired together because their data types (numeric, string, array, cluster, etc.) do not match. Show the Context Help window to see what data type is required.
    The type of the source is Cluster Refnum
        typedef 'Arduino Resource.ctl'
        cluster of 4 elements.
    The type of the sink is typedef 'Arduino Resource.ctl'
    cluster of 4 elements.
    ...any clue why this comes up`?
    I gonna attach mz Vis
    Any help is very much appreciated!
    Thanks,
    Chris
    Whew - where to begin?  It's like having someone ask you how to rebuild an engine and you have to explain how a socket wrench works...
    You chose a tall task as your first project.  I suggest you at least go through this tutorial if not rhis one before we can begin to help you.
    Bill
    (Mid-Level minion.)
    My support system ensures that I don't look totally incompetent.
    Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

  • Labview server view data remotely

    Is there a way that I could set up LabVIEW as a server so I could view data when I'm not at the computer?  Basically I have a program running, and it's constantly spitting out data to a .txt file, and I was wondering if there was any way that I could view the contents of that .txt file from another computer
    Much thanks,
    M.

    You have a couple options:
    1: You could write a VI to act as a server using the built-in TCP VIs such that a VI on the client PC could send requests for parts of that text file and the "server" could respond with that data. The TCP VIs are located in your functions palette at Data Communications > Protocols. Also take a look at the shipping TCP examples at Help > Example Finder... > Networking > TCP & UDP
    2: If you need a way to display the data, then remote front panels may be the better route. You can write a VI such that the front panel can be viewed and controlled from a web browser on another machine. This way you could update the front panel with the requested data. This is not included in Base Development of LabVIEW but can be purchased separately.
    Developing Remote Front Panel LabVIEW Applications
    --Michelle
    Instrument Control R&D
    National Instruments
    Instrument Control
    Machine Vision

  • Why does Labview Server shutdown during TestStand execution

    Greetings All,
         Please forgive me if this question should've been posted on the TestStand side.
         What would cause the Labview Adapter Server to shutdown?  I've noticed that each time I click the Test UUT's (green execution arrow) button that during the analysis part before the client actually brings up the serial numbers screen, the Labview Adapter Server initializes.  The task bar would always show TestStand 2010 and Labview 2010 (Getting Started screen).  We are running a batch sequence that is monitoring four (4) uut's during an ESS profile and performing various testing at three (3) different temperature levels.  The process is kind of lengthy (2-1/2 days).  From what I could see the test was in a loop, as usual, waiting for a response from the thermal chambers internal relays which tell the TestStand program that the chamber has begun to move to the next temperature.  I notice that there was an ERROR displayed on the side of one of the batch sequences which was reading one of the PXI-6509 inputs.  I took a screen capture at that point before doing anything further.  I didn't notice it at first but looking at the screen capture again I noticed that Labview was missing from the task bar.
         I am wondering what could have caused this and if there is anything to prevent this from bitting me again.  This client sequence was running well for two (2) days and this happened with less than 12 hours of testing to go.  Thank you for any information that you provide with regards to this question.
    Regards,
    Scott

    Hi snowpunter,
         Sorry I didn't get back to you sooner.
         Unfortunately there are too many users that think too much and close things before my team has a chance to look at the failure when it happens.  There is a remote possibility that someone closed the Labview application by accident.  There are many times that the Labview screen pops up in front of the TestStand screen while the sequence running and someone closed out Labview because they couldn't see the execution.
         It doesn't appear that there are multiple threads trying to access the PXI-6509.  The contractor that did most of the programming utilized a lot of Batch Synchronizations to prevent this kind of thing from happening, not that it isn't possible.
         I'm wondering if there is a way to disable the operator from shutting down Labview, whether by the RED "X" in the top right corner or Menu-File_Close.  If so, How would I accomplish this?  Thanks in advance for any reply you have to offer.
    Thanks,
    Scott

  • Why does my LabVIEW Run-time server return the message "source does not exist Last UI message: Start Execution"?

    I am trying to build a stand-alone application on a target pc for which I have built a LabVIEW server that TestStand can use as an adapter.
    In order to do this, I searched this site and found the topic: "How do I build and Use the LabVIEW Operator Interface as a LabVIEW ActiveX Run-time server?" After following the procedure to the letter, I ran the testexec.exe file as instructed and loaded my sequence file. As soon as I try to "Single Pass" or "Test UUT" I get an error which says "source does not existLast UI message: Start Execution". This error appears when running the testexec.exe file on the target pc or the development pc.
    I have found though, th
    at if I open the Operator interface through the Start: Programs>National Instruments>TestStand>Operator Interfaces>LabVIEW then the sequence file runs without these errors.
    Any ideas why this is happening?

    Hello Robroy,
    The KB you mentioned explaines how to build the LV Operator Interface (OI). So, I assumed you built the LV OI and also configured the LV adapter to use the TestStandGUILVRTS server without problems.
    The error you are getting may be due to missing VIs. In other words, the LabVIEW OI may not be finding all the VIs your sequence is calling.
    In order to deploy sequences that call VIs, you need to first run Tools >> Assemble VIs for Runtime Distribution. This tool gets all the VIs your sequence needs and saves in a separate directory.
    For more information, you may check the TestStand User Manual chapter 17, it describes how to distribute TestStand and sequences.
    Regards,
    Roberto Piacentini
    Applications Engineer
    National Inst
    ruments
    www.ni.com/ask

  • Publishing front panels with web server

    Hello,
    I'm working with LabView 7.1 and trying to publish a front panel by means of the web server.
    The problem is that I'm only able to connect to the VI through the internet when both , the host and the remote are networked. 
    When I try with computers outside that network the browser doesn't find the webpage.
    Thank you for your help
    Lian

    You need to know:
    The public IP of your router.
    The private IP of your LabVIEW server.
    The port used by your server.
    First you need to forward the port on your router. Basically, you need to tell the router that incoming NEW connections to a certain port of the public IP of the router should get forwarded your server. (Without forwarding, the router only works for outgoing connections). Once the port is forwarded, clients located on the outside need to connect to the public IP of your router.
    Possible complications:
    Your ISP might block certain incoming ports for security reasons. In this case you can configure a different port for the server.
    With some routers you will not be able to connect to your server (for testing) with a client located on the same LAN via the public IP of the router. Only routers that incorporate a loopback proxy support this. What is the brand and model of your router?
    Good luck!
    LabVIEW Champion . Do more with less code and in less time .

  • How to capture LabVIEW value through pda

    工程師先生您好﹔
    　　現在我要寫一個程式是利用pda來抓取我LABVIEW上的值，server端的數值有改變，但無法將資料傳入pda，請問我這個程式是哪裡有寫錯，麻煩各位LABVIEW幫我解決這個問題，謝謝．
    　　若今日我想要把LabVIEW上有多個顯示元件，我該如何撰寫才能將這些顯示元件的值讀入pda
    note：Data Server - Windows Mobile　　(電腦)
    　　　Data Client - Windows Mobile         (pda)
    Attachments:
    Data Server - Windows Mobile.vi ‏20 KB
    Data Client - Windows Mobile.vi ‏20 KB

    Here is the code you can use
      String profileValue=  getOADBTransaction().getProfile("profile Name");Thanks
    --Anil                                                                                                                                                                                                                                                                                       

  • Opc server into shared variable

    Hello,
    I am writing a program to read hundreds of OPC signal from a server. The server is a  localserver in the PC but its not a Labview server. My labview program reads the OPC signal thru data socket into a Labview Library.(Variable type=single process)
    This way is working but not optimal. I have read in Help that I can use a Network-published shared variables. Does this Network-published be able to read the signal from my opc server thru a network path without using data socket? Must it be a Labview server? 
    this is an example for my opc address
    opc://localhost/hteControl_OPC_DA_Server/PLC_FI010_ValueLimit_SP
    Thanks
    Solved!
    Go to Solution.

    fmpfmpf wrote:
    Hello,
    I am writing a program to read hundreds of OPC signal from a server. The server is a  localserver in the PC but its not a Labview server. My labview program reads the OPC signal thru data socket into a Labview Library.(Variable type=single process)
    This way is working but not optimal. I have read in Help that I can use a Network-published shared variables. Does this Network-published be able to read the signal from my opc server thru a network path without using data socket? Must it be a Labview server? 
    this is an example for my opc address
    opc://localhost/hteControl_OPC_DA_Server/PLC_FI010_ValueLimit_SP
    Thanks
    LV-DSC (Data Logging and Supervisory Control) aloows you to "bind" the NSV to an OPC server.
    As long as the server os OPC compliant it should work and has ben the case for me.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Labview OI executable hangs when started.

    Hello,
    Specs:
    2 Systems running:
    Dell Precision workstations 670
    Windows 2000
    Labview 6.1
    TestStand 2.0.1
    I have compiled the Labview custom Operator Interface (slightly modified) into an executable file (SPR_TSM.EXE) which I installed on each machine. However, on one of the machines when running the executable, the application just hangs at the initial "loading" screen without even displaying the window (just a white square). Then I need to end the process from the task manager. The only way I have found to run the application is to open the SeqEdit.exe (sequence editor) which in turns opens my application because of using the TestStandLVGUIRTS server (!?). The same application runs OK in the other system. I have tried in several user accounts and the problem persists even for users belonging to the ADMIN group. All permissions in the C: driver were set to FULL CONTROL for EVERYONE.
    Please let me know what can else I do to solve this problem. Thanks for your help.

    Thanks very much for the info. It seems to be working, however not as I expected. For this machine I have the application (spr_tsm) running from a batch file that does:
    spr_tsm /RegServer
    spr_tsm
    I tried just registering the application in the command prompt and then running the executable, but it still "hangs" when called from the shortcut. On all occasions I have confirmed that the TestStandLVGUIRTS is listed in the dcomcnfg screen.Another interesting note is that when uninstalling the application there is always an error "Write permission to the Registry denied, LABVIEW Server not unregistered" but it removes TesStandLVGUIRTS from the dcom list. Again, thanks a lot for the info!

  • How to call Python Scripts throght Labview

    Hi all,
    I am new to this community. Need some inputs  for following Questions
    Questions:
    1)  How can I call python script from LabView?
     (Basically this python script calls some other DLL and print some message, to run the script using Python net in my application .To run my script in python net using following commands: import python script name )
    2)  In how many ways we can call Python scripts from labview?
    I have tried with this option "System Exec.vi "in labview , able to calling pythonnet but unable to send commands and arguments to run python script(i.e  import python script name ). 
     If anyone have samples".VI " please send to me. If you people want any information and clarification  from my side please let me know. Thanks in advance.
    Regards,
    Sambasivareddy

    One way is to create a client server app and to send arguments to python (and back) over TCP/IP. This work very well.
    There is an example on the old OpenG Website about this. Look it up.
    Python client to LabVIEW Server.
    PJM
    Message Edited by PJM_Labview on 03-12-2008 09:00 AM
    Got EasyXML?
    JKI.VIPM.EasyXML.OpenG.LAVA.Builder.blog

  • How can I create a Teststand (1.0.3 or 2.0) distribution without having all of the VIs (6.0.2 or 6.1) in the same directory?

    How would I create a Teststand distribution of LabVIEW VIs and maintain the test VI directory structure that I want?
    I know that I have to use the application builder to build the custom operator interface, configure it as an ActiveX server, and launch the Teststand engine installation.
    The only problem that I have is using the VI packager which puts all of the test code and sequences in a single directory.
    This gets quite messy. There are just over 1000 files in the neatly orgainzed directory structure that I have now. (this includes support files, dll's and such)
    I have read brief appnotes on configuring the ini file(s) to use
    the vi search path that I want, but have not been able to get this to work. Maybe I'm not updating the correct ini? or have to include each subdirectory?
    I have currently upgraded from LabVIEW 6.0.2 to 6.1
    I am currently using Teststand 1.0.3
    I have not upgraded to Teststand 2.0 yet because I have not decided if I want to build at this revision or go through the extra work to mass compile Teststand at LabVIEW 6.1, install the LabVIEW 6i VI Packager Fix, and update the new Teststand LV operator interface with my changes.
    At present, I'm not getting the results I want and am quickly running out of time. I have to deliver the project by the 14th of July 2002.
    Sorry for the long question and thanks for you help.

    Hi,
    I dont think the problem is really related to using the VI Packager but more to how the OI interface applications relates to labVIEW File constants.
    If you are using the LabVIEW as the ActiveX Server then there should be no problems. But if you are using the Runtime LabVIEW server such as 'TestStandLVRTS' then the file constant would return different paths.
    eg for the Default Path you would get 'C:\TestStand\Components\User\RuntimeServers\LabVIEW' instead of 'c:\Program Files\National Instruments\LabVIEW'.
    Attacted is an example to show how to change these paths when using your runtime server. Unzip this into your teststand examples folder
    Put the INI file in the location of the \user\runtimeservers\labview folder.
    Change the labview adapter t
    o use TestStandLVRTS.exe. You can run the example sequence from either the OI or seqeditor.
    I hope this helps
    Regards
    Ray Farmer
    Regards
    Ray Farmer
    Attachments:
    UsingLVOI.zip ‏20 KB

  • How can I use a COM object that does not have a type library?

    Hello,
    I've created a com server in python for which I do not have a type library. I am able to call functions for this application in Python, TCL, I'm sure VB, etc. without the type library.
    Must I have a type library registered to use this COM object with Labview? I was hoping I could simply supply the name to the refnum (or the GUID) then call functions by passings strings to the invoke node. This does not seem to be possible - am I missing something?
    In the event that I cannot use a com server without a type library. Any recommendataions on how to create one? I'm wondering if I can use the same GUID and create a shell in LabWindows which generates the IDL/TBD file I need for Labview to see my
    com server.
    Any help is greatly appreciated.
    73,
    Timothy

    Timothy Toroni wrote:
    > Thanks for the info, however their example is labview server and
    > python client. I'm going the other way. It's good to know about
    > LabPython though...
    >
    > As of now, it seems to be there is no way to use a COM object without
    > a type library from inside LabView.
    Yes that is true. LabVIEW needs that to configure the Property and
    Methode Nodes correctly. Otherwise it would need to have a special
    Property and Method Node with a configuration dialog similar to the Call
    Library Node, but a LOT more complicated. Not sure many people could
    make use of that, and it would be a very tiring experience trying to get
    things setup in that way, by going through the edit, test, and crash
    cycle over and over again.
    Rolf Kalberm
    atter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Why do I get -18001 Errors using Customised TestStand User Interface

    Hi all
    I have a problem when attempting to run my application on my host NT PC. I have a customised operator interface to TestStand written using Labview 5.1.1 and built using the LabVIEW application builder. I am running the TestStand Development (Run-Time) System on my host PC.
    The problem is that as soon as I go to run my sequence of vis (mass compiled using the same version of LabVIEW and assembled for run-time distribution) I receive the error '-18001 VI Not Executable.'
    I think this is probably to do with how I've included the ActiveX server in my LabVIEW User Interface application, but knowing very little about ActiveX I'm not sure exactly what the problem is.
    If anyone
    has any ideas, I would be extremely grateful for any assistance you could offer. My TS version is 1.0.1
    Thanks
    Dave

    David,
    I would like to add to Richard's input. The typical reasons a VI cannot be executed that cause this message are:
    1) There is an error in the VI such that the run arrow of the VI is broken when the VI is open in the LV development environment. This problem is usually easy to debug because you should get the error (shown below) when running your sequence in the sequence editor using the default "LabVIEW" ActiveX server provided by the LV development environment (not the LV ActiveX server provided by your operator interface which is by default named "TestStandLVGUIRTS" ).
    An error occurred in the 'MyVIStep' step of the 'MainSequence' sequence in 'MySequence.seq'.
    LabVIEW : VI is not executable.
    An error occurred accessing the LabVIEW ActiveX automation server. Error Code: -18001
    2) The same error will occur when
    a. you are using any LV ActiveX server other than the "LabVIEW" server provided by the LV development environment, AND
    b. at least one of the called VI was not assembled for distribution properly. This means that not all test VIs and their *entire* hierarchy were distributed.
    I am not sure exactly what you have done so have compiled some information that I think will help. Below I have included the document, Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter, which will appear in the NIDZ shortly. Another useful document is the NIDZ document Distributing LabVIEW Test VIs, which you can obtain from our website. Read these documents before preceding with the steps immediately below, which give you an example process for distributing. This may help provide a better understanding and guidance in the distribution process. We are working to simplify this process in future versions of TestStand.
    For the following example distribution I recommend that you are use default shipping code so that the problem is not complicated with potential errors added through customizations you have made.
    Building The Operator Interface
    The following are steps if you are using a LabVIEW operator interface.
    1) Copy the contents of \OperatorInterfaces\NI\LV to \OperatorInterfaces\User\LV.
    2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
    3) In LabVIEW Select Tools>>Build Application or Shared Library
    4) In the builder click the Load button and load \OperatorInterfaces\User\LV\testexec.bld. This build script is configured to create testexec.exe that contains the LV ActiveX server with the name of TestStandLVGUIRTS (see the Application tab of the builder).
    5) In the builder click Build.
    6) Once the application testexec.exe is built, run it once so that the server TestStandLVGUIRTS is automatically registered. You do not need to run a sequence. Close texec.exe.
    Creating a LabVIEW Run-time Server
    If you are using the LabVIEW operator interface then skip this section. The following steps are meant for those who use an operator interface written in a ADE other than LabVIEW. They provide you with a LabVIEW run-time server that is used by TS to run your VIs.
    1) Copy the contents of \Components\NI\RuntimeServers to \Components\User\RuntimeServers.
    2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
    3) In LabVIEW Select Tools>>Build Application or Shared Library
    4) In the builder click the Load button and load \Components\User\RuntimeServers\LabVIEW\TestStandLVRTS.bld. This build script is configured to create TestStandLVRTS.exe that contains the LV ActiveX server with the name of TestStandLVRTS (see the Application tab of the builder).
    5) In the builder click Build.
    6) Once the application TestStandLVRTS.exe is built, run it once so that the server TestStandLVRTS is automatically registered on your development machine. Close TestStandLVRTS.exe.
    Assembling the Test VIs for Run-Time Distribution
    This distribution process uses one of the shipping TS examples that calls LV VIs.
    1) From LV mass compile all VIs in the directory \Examples\AccessingArrays\UsingLabVIEW\. Please make sure that there were no error messages in the Status tab of the Mass Compile dialog box.
    2) In the sequence editor open \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq
    3) Confirm that the sequence runs without problem.
    4) In the sequence editor select Tools>>Assemble Test VIs for Run-time Distribution.
    5) If you are using TestStand 2.0 select \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq as the file from which the VIs should be assembled.
    6) Set the target directory to be something distinct like C:\temp\AssblVIs.
    7) If you are using TestStand 2.0 skip adding Dynamic VIs
    8) Save with or without diagrams. Its your choice.
    Change Search Directories
    Once the VIs are assembled successfully, you must add the new target directory to the TS search directories.
    1) In the sequence editor select Configure>>Search Directories.
    2) Add your target search directory (e.g. C:\temp\AssblVIs) to the search directories.
    3) Close the Edit Search Directories dialog box.
    4) Confirm that your sequence steps now reference the assembled VIs. Right click on a step in the sequence and select Specify Module.
    5) The dialog should show that the code module is found in the target directory (e.g. C:\temp\AssblVIs) that you just added to the search directories.
    6) Run the sequence. This is the initial test to see if the VIs are assembled properly.
    Switch the LV Adapter to use the TestStandLVRTS server or TestStandLVGUIRTS
    1) In the sequence editor select Configure>>Adpaters.
    2) In the Configurable Adapters control select the LabVIEW Standard Prototype Adapter and then click the Configure button.
    3a) If you are not using the LV operator interface then switch the ActiveX server to TestStandLVRTS.
    3b)If you are using the LV operator interface then switch the ActiveX server to TestStandLVGUIRTS.
    4) Close the adapter configuration dialog boxes. You will get a couple of questions boxes. Just click OK each time.
    5) Now run your sequence. If successful you are no longer using the LV development environment to run your VIs. This shows that the VIs were assembled correctly, the LV ActiveX server is working properly and that the search directories are configured properly.
    You can now try and run the sequence using your operator interface on you development computer. If this test works it means that you have also confirmed that your operator interface is working correctly with all the other components. Now it is just a matter of moving all the component correctly to the target machine.
    Distributing Components
    -To distribute your operator interface use the distribution tool of the application development environment (ADE) in which you built your operator interface.
    -To distribute the TS engine using the Run Engine Installation Wizard tool. This tool is typically not used for distributing your sequences and VIs, which you will probably distribute more frequently than the TS engine. It does distribute and register your LV run-time server (if you are using one) as long as you have stored it in \Components\User\RuntimeServers. It also distributes other TS components that you have stored under the directory \Components\User\.
    -You can use whatever distribution system you like to distribute your VIs and sequence files (e.g. ZIP and network transfer are popular) . Ensure that you distribute the assembled VIs and not the development VIs. Also ensure that the location of the VIs on the target machine is one of the TS search directories.
    Hope this helps.
    Regards,
    Kitt
    =========================================
    Title:
    Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter
    The general outline of the components to be distributed and the actions to take are followed by a more detailed description.
    Components that need to be distributed:
    TS engine
    Operator interface
    LabVIEW executable that will act as a LabVIEW ActiveX automation server (If the operator interfaces is written in LabVIEW, it can function as the LabVIEW ActiveX automation server.).
    LabVIEW run-time engine
    LabVIEW test VIs
    Test sequence files
    Actions before distributing:
    It is recommended that you test the distribution components on the development machine before you distribute them to your target machine. In this manner you can more easily debug errors that you may encounter
    Create the executable that will serve as your LabVIEW ActiveX server on the target machine (components 2 or 3 above).
    Assemble the test VIs for distribution.
    Update the TestStand search directories so that the sequences reference the assembled VIs.
    Configure the LabVIEW Standard Prototype Adapter to use the LabVIEW ActiveX server that you will install on the target machine.
    Test the distribution components on the development machine.
    Enter section headings, separating each section with a line break:
    TS Engine Component
    Operator Interface Component
    LabVIEW ActiveX Server
    Configuring the LabVIEW Standard Prototype Adapter
    LabVIEW Run-time Engine Component
    Assembling your Test VIs for Distribution
    Note
    TS Engine Component
    With any TestStand distribution you must install the TestStand runtime engine on the target machine. The Run Engine Installation Wizard tool, found under Tools menu of the Sequence Editor, facilitates this process. The wizard tool will create two files, SetupTSEngine.exe and TSEngine.cab. Move the two files to your target machine and run SetupTSEngine.exe to install the TestStand engine.
    These installation files include the current configuration settings that exist in the Sequence Editor at the time the tool is invoked. It also includes all process models, TestStand types and step type modules. If you have customized components of TestStand and saved them under the directory TestStand\Components\User, then the components will also be included with the engine installation.
    You must purchase at least a base deployment or debug deployment license for each machine on which you install the TestStand engine.
    Operator Interface Component
    You will also need to install an operator interface executable on the target machine. This program acts as a client to the TS runtime engine, controlling the execution of sequences and displaying their progress. TestStand ships with several versions of TestStand operator interfaces, which are written in different application development environments (ADE). For distributing the operator interface executable, refer to the application development environment in which it was created.
    LabVIEW ActiveX Server
    You must have a LabVIEW ActiveX server on the target machine. TestStand uses the LabVIEW ActiveX server to run VIs using either the LabVIEW development environment or the LabVIEW runtime engine. The LabVIEW ActiveX server is provided by either LabVIEW development environment or by any LabVIEW executable that has been built with �Enable ActiveX Server� selected. This setting can be accessed in the LabVIEW Application Builder during the build process. When this preference is enabled, you must enter a server name. You will use the server name to configure the LabVIEW Standard Prototype adapter in TestStand.
    If your operator interface is written in LabVIEW, then it can act as the LabVIEW ActiveX server on your target machine. TestStand ships with two operator interfaces written in LabVIEW. The standard LabVIEW operator interface is located in TestStand\OperatorInterfaces\NI\LV, while a simplified version is located in TestStand\Examples\OperatorInterfaces\Simple LV. LabVIEW buildscripts are provided for these applications to facilitate building an operator interface in the latest version of LabVIEW. The settings of these buildscripts are such that the applications are LabVIEW ActiveX servers with the server names of TestStandLVGUIRTS for the standard operator interface, and TestStandSimpleLVGUIRTS for the simple operator interface. The applications register the servers the first time they are executed. If you want to manually register or unregister one of the servers, you can invoke the executable with the /RegServer and /UnregServer command-line arguments respectively.
    If your operator interface is programmed in a language other than LabVIEW, then you will need a separate LabVIEW executable to provide the LabVIEW ActiveX server on your target machine. For this purpose, TestStand ships with a LabVIEW run-time server application located in TestStand\Components\NI\RuntimeServers\LabVIEW. A LabVIEW buildscript is provided for this application to facilitate building a run-time server in the latest version of LabVIEW. The settings of this buildscript are such that the application is a LabVIEW ActiveX server with the server name of TestStandLVRTS.
    Note: When an ActiveX executable server is accessed, the executable is launched automatically if it is not already executing.
    Configuring the LabVIEW Standard Prototype Adapter
    When TestStand runs a VI using the LabVIEW Standard Prototype adapter, it does so using a LabVIEW ActiveX server. By default the adapter is configured to use the �LabVIEW� server, which is provided by the LabVIEW development environment. If you do not have the LabVIEW development environment on your target machine then you must configure the LabVIEW Standard Prototype adapter within TestStand to use a different server (e.g. TestStandLVGUIRTS, TestStandLVRTS, or TestStandSimpleLVGUIRTS).
    To configure your LabVIEW Standard Prototype adapter, select Configure>>Adapters from the menu. In the Adapter Configuration dialog box that appears, select the LabVIEW Standard Prototype Adapter in the Configurable Adapters section. Click the Configure button. You can select or type a server name in the Select or Type Which LabVIEW ActiveX Server to User control. If your server name is not in the list you will need to type it.
    As explained in the LabVIEW ActiveX Server section above, TestStand ships with LabVIEW buildscripts to build a LabVIEW operator interface and a LabVIEW run-time server application. These applications are LabVIEW ActiveX servers with server names TestStandLVGUIRTS and TestStandLVGRTS, respectively. You can configure you LabVIEW Standard Prototype adapter to use one of these servers.
    LabVIEW Run-time Engine Component
    If any of your sequence steps use the LabVIEW adapter or if your operator interface is written in LabVIEW, then you must install the LabVIEW runtime engine on the target machine. It is important that your LabVIEW run-time engine is the same version as the VIs that TestStand executes.
    You can find installation files for the LABVIEW 5.1 run-time engine in the LabVIEW installation directory, Labview\APPLIBS\installs\RunTime. In addition, you can choose to automatically distribute and install the LabVIEW run-time engine with the distribution of a LabVIEW executable. Refer to LabVIEW documentation.
    Assembling your Test VIs for Distribution
    After distributing TestStand, you must ensure that your sequences are able to locate the VIs they call, and the VIs must be able to locate their required resources.
    One common mistake is to simply copy the original VIs from the development machine to the target machine. Once you have configured your LabVIEW Standard Prototype adapter to use a LabVIEW ActiveX server other than LabVIEW, your sequence will not be able to execute your original test VIs that your sequences call.
    TestStand provides the Assemble Test VIs for Distribution tool, which gathers test VIs and their required resources, and places them in a common location for distribution. You can then modify your TestStand search directories so that your sequences reference the assembled VIs. These topics are covered in the NIDZ document Distributing LabVIEW Test VIs.
    Links: See Distributing LabVIEW Test VIs below
    Note
    Remember to test your distribution components on your TestStand development system before distributing TestStand. If the execution does not work on the development system it is not going to work on your target machine. On your development machine you have more ability to debug problems you may encounter.
    Note: One common problem of testing distribution components on your TestStand development system is that your sequences reference the original Test VIs instead of the assembled test VIs. Refer to the NIDZ document Distributing LabVIEW Test VIs for assistance.
    Once the components work on your development machine, you are ready to install them on your target machine. The order in which you install these components on the target machine is irrelevant.
    ==============================================

Maybe you are looking for