Is it possible to shutdown TestStand LabWindows/CVI operator interface programmatically?

Hi,
Like the title says, I'm trying to find a way to shutdown TestStand operator interface automatically after sequence execution is completed.
Any suggestion is appreciated, thanks in advance.

Thank you for your reply.
I did a loop but it wouldn't work :s
I managed to create an ActiveX button to exit test stand.
I found an example within the TestStand Course I and II.
static void ExitApplication(void)
 VBOOL canExitNow;
 TSUI_ApplicationMgrShutdown (AppManagerHandle, &errorInfo,&canExitNow);
 if (canExitNow)
  QuitUserInterface(0);
// the ApplicationMgr control sends this event when it is ok to exit the application.
HRESULT CVICALLBACK ApplicationMgr_OnExitApplication(CAObjHandle caServerObjHandle, void *caCallbackData)
 ExitApplication(); 
 return S_OK;
void CreateTSEngineHandle ()
 GetObjHandleFromActiveXCtrl  (panelHandle, PANEL_APPLICATIONMGR,&AppManagerHandle);
 GetObjHandleFromActiveXCtrl  (panelHandle, PANEL_EXIT,    &AppExit   );
 TSUI__ApplicationMgrEventsRegOnExitApplication (AppManagerHandle, ApplicationMgr_OnExitApplication, NULL, 1, NULL);
 TSUI_ApplicationMgrConnectCommand (AppManagerHandle, &errorInfo, AppExit, TSUIConst_CommandKind_Exit, 0,
            TSUIConst_CommandConnection_NoOptions, NULL);
 TSUI_ApplicationMgrGetEngine (AppManagerHandle, &errorInfo,&EngineHandle);
 TSUI_ApplicationMgrStart     (AppManagerHandle, &errorInfo);
 TS_EngineGetGlobals(EngineHandle,NULL,&Globals);
This way I click my QuitButton and it calls the the ActiveXExitButton witch calls the ExitApplication function.
The ApplicationMgr control sends ApplicationMgr_OnExitApplication event when it is ok to exit the application.
Hope this was clear enough and I hope this may be helpfull for someone else.
I apreaciate all the help.
Regards,
Daniel Coelho
Daniel Coelho
VISToolkit - http://www.vistoolkit.com - Your Real Virtual Instrument Solution
Controlar - Electronica Industrial e Sistemas, Lda

Similar Messages

  • Send UI meassages from teststand sequence to Simple CVI Operator Interface with Asynchronous Timer

    Hello,
    Is it possible and how is it possible to send UI meassages from a teststand sequence to the Simple CVI Operator Interface with Asynchronous Timer which could be downloaded from NI Hompage. I use this problems because it is more stable than the standard OIs
    regards samuel

    This post could help:
    http://forums.ni.com/ni/board/message?board.id=330&message.id=7567
    Regards.

  • Can anyone explain the odd behaviour of the CVI Operator Interface?

    This is probably really related to CVI in general, but I think people should be aware of this behaviour. If tracing is enabled and a program executing, moving the mouse cursor over the Menu bar area of the Operator Interface program increases the execution of the test program dramatically. Anywhere else slows it down! Could this have any effect during critical test runs? Is there a way to force the fast execution. (i.e. to disable whatever message processing is going on when the mouse cursor is over the rest of the window?)

    Brian,
    You did not mention what is the CVI operator interface that you are using. In the Simple CVI OI, which is located at \Examples\OperatorInterfaces, the behavior you mentioned may occur.
    It is mainly because it uses a CVI timer to poll UIMessages, and the Timer Control runs in the same thread as the User Interface (CVI Panels). Because they both run in the same thread, when you move your mouse Windows handles the mouse move and repaint any window if necessary. While doing this, it stops all the other tasks that is running in the same thread, which means, the timer stops to tick and UIMessages are not handled for some time. In addition, the TestStand Engine executes synchronously with UIMessage handling, so if msg
    s are not handled the Engine pauses the execution.
    Finally, there is an example that ships with CVI under
    \Samples\Toolbox\AsyncDem.prj that shows how to use asynchronous timers. In other words, a timer that runs in a different thread different than User Interface. I also modified the Simple CVI OI to use this asynchronous timer, check the attached zip file.
    Regards,
    Roberto P.
    Applications Engineer
    National Instruments
    www.ni.com/support
    Attachments:
    Simple_CVIAsync.zip ‏176 KB

  • Remove step icons from CVI Operator Interface to improve execution performance

    The CVI Operator Interface updates the icons for each step (lower right) when tracing is enabled. Can these be stopped but the steps still visable and would this improve execution performance.

    Hi Dave,
    I take it you are using the old style Teststand Operator Interface.
    The only way would be to modify the code in the exedisp.c, in UpdateOnStepChange() function. Just comment out the SetCtrlBitmap() function there are two calls in this function.
    As to whether it is going to make a noticable different in performance, well that depends on the spec of the controller (PC), graphics card etc. you are using. But you probably wouldn't notice any diference.
    Before you make any changes, copy the sub-folders from the NI folder to the User folder and work from the User folder.
    Regards
    Ray FarmerMessage Edited by Ray Farmer on 05-07-2005 06:29 PM
    Regards
    Ray Farmer

  • Update Station Globals from LAbWindows/CVI user interface

    Hi,
    I am having a requirement such that i need to update a station global variable to true or false based on the click on a button present in User Interface.
    My Setup:
    Labwindows/CVI 8.5
    TestStand 4.2.1
    Please advice me.
    Solved!
    Go to Solution.

    Hi,
    first thing, why have you posted this query twice, http://forums.ni.com/t5/NI-TestStand/Update-Station-Globals-from-CVI-UI/m-p/1317023
    to be able to update a StationGlobal, you first need to get a reference to the Engine, this can be done using ApplicationMgr.GetEngine()
    Once you have that reference you can then get a reference to the StationGlobals by the use of Engine.Globals(). this returns a PropertyObject.
    So now you can use the SetVal methods to set your boolean, eg PropertyObject.SetValBoolean("MyBoolean",  0,  True)
    hope this helps
    Regards
    Ray Farmer

  • TestStand 4.0 Operator Interface Changes Not Seen

    Hi guys,
    Ive worked with TestStand before, but now im trying to modify the operator interface (located C:\Program Files\National Instruments\TestStand 4.0\UserInterfaces\NI\Simple\LabVIEW).  Well, i try to modify the VI in the project, but i cant see my changes when i run the VI.  Ive tried building the executable and see that hte executable does get rebuilt, but none of my changes show up. 
    Also, how does the "entrypoint 1" button get renamed to something else when the VI actually runs?
    thanks
    jeff

    Looking at the help, it appears that the TestStand button only uses the system color unless it is in toolbar mode. If you want to use a LabVIEW button instead, you can implement the button action by calling <SequenceFileViewMgr>.GetCommand(...).Execute().
    This thread might help you determine when to dim or enable the button: http://forums.ni.com/ni/board/message?board.id=330&message.id=15720
    Here is the button help:
    BackColor Property
    Syntax
    Button.BackColor
    Data Type
    Color
    Purpose
    Specifies the background color for the Button control.
    Remarks
    When you set Style to ButtonStyle_ToolBar, this setting applies to the face and border of the button. When you set Style to ButtonStyle_Standard, the button face adheres to the system settings, and this setting affects only the border of the button.
    See Also
    ButtonStyles
    ForeColor
    Style

  • Unable to include Operator Interface in TestStand deployment

    Hello.  I have created a test system using TestStand 3.5. 
    There is only one sequence file, and this sequence calls several VIs
    that I have created in LabVIEW 8.0.  I would like to distribute
    this test system to a target computer, which will then run the default
    Operator Interface.  No bells and whistles, just plain and
    simple.  However, I'm running into problems.
    First, I created a Workspace file in TestStand.  I then added a
    Project to it.  In the Project, I added all necessary files for my
    project (the sequence file as well as all of the custom VIs). 
    Then I proceeded to follow the TestStand reference manual in order to
    deploy my system.
    For reference, text in italics is the reference guide and text in bold is my comments.
    Deploying the TestStand Engine
    1. Launch the TestStand Deployment Utility by selecting Tools»Deploy
    TestStand System from within the sequence editor.
    I did this, and set up my build how I wanted it.
    2. On the System Source tab, enable the Deploy Files in TestStand User
    Directories option.
    This option collects files from the <TestStand>\...\User
    directories, so that any customizations that you have made to process
    models, step types, language strings, and so on, will be distributed to
    the target computer.
    I did this, and copied my Operator Interfaces\NI folder to Operator
    Interfaces\User.  This would assure (I hope) that I would have the
    default operator interfaces included in my project.
    3. On the Installer Options tab, enable the Install TestStand Engine
    option.
    Done.
    4. On the Installer Options tab, click Engine Options to launch the
    TestStand Engine Options dialog box, which you use to select the
    TestStand components that should be present in the installer.
    Done.  Everything is checked.
    In the TestStand Engine Options dialog box, expand Operator
    Interfaces»Full-Featured in the tree view.
    a. Click the X next to LabWindows/CVI to include the
    Full-Featured LabWindows/CVI Operator Interface in the engine
    installation. The X should become a green checkmark.
    b. Click OK to accept the new settings and close the dialog box.
    This is where things go wrong.  There is NO Operator Interfaces box in my tree view.  It simply doesn't exist.
    I've tried several different builds using different strategies. 
    I've done builds with the CVI operator interface in the User directory,
    and I've also tried copying over the files manually.  On the
    target computer, I've always gotten either an error message (Could not
    open the TestStand Engine), or else TestStand opens in evaluation
    mode.  In both cases, my custom VIs and sequence files are nowhere
    to be seen.  Can anyone shed some light on this?  It's
    driving me a bit crazy!
    Thanks very much,
    Brett Gildersleeve

    Hi Brett,
    Whenever you deploy your TestStand application to target machines, you will always needs a license.  The licenses for distributing TestStand are different than for distributing LabVIEW and LabWindows/CVI code modules.
    LabVIEW does not require you to purchase any run-time licenses for a deployment system. You can even run LabVIEW VIs in VI format (not executables) from TestStand without using the development environment and without an additional license.
    In order to run LabWindows/CVI code modules, you will need the LabWindows/CVI Run-Time engine which is also available free of charge.
    Regarding TestStand, you will need a license for each machine that runs a TestStand sequence. TestStand has three types of licenses which are the TestStand Development System License, the TestStand Debug Deployment Environment License, and the TestStand Base Deployment Engine License.
    TestStand Development System License
    The TestStand Development System License is required for any test sequence development and/or editing of existing TestStand sequence files that you perform within the TestStand Sequence Editor or programmatically using the TestStand API.
    TestStand Debug Deployment Environment License
    The TestStand Debug Deployment Environment License gives you maximum flexibility for deploying TestStand and LabVIEW, LabWindows/CVI, and Measurement Studio-based systems. This license allows you to install the development versions of TestStand, LabVIEW, LabWindows/CVI, and Measurement Studio, along with any corresponding add-on toolkits, so that you can debug your test application on your deployed test station. This license does not include the ability to perform any development tasks within the TestStand Sequence Editor or programmatically using the TestStand API.
    The TestStand Debug Deployment Environment License has debugging capabilities including settings breakpoints, monitoring variable values, and stepping into test code directly from the TestStand sequence.
    (Note: This license does not provide the software but rather gives you the right to install a previously purchased piece of software on the target machine.)
    TestStand Base Deployment Engine License
    The TestStand Base Deployment Engine License is the minimum license required for all deployed TestStand-based applications. This license allows you to deploy the TestStand Engine, a TestStand Operator Interface, and TestStand sequence files to the single test station for which the license is applicable.
    The TestStand Base Deployment Engine License provides simple sequence debugging capabilities, including setting breakpoints and single stepping through test sequences in your Operator Interface. You cannot save sequences and open the sequence editor.
    I hope this clears things up.
    Best Regards,
    Jonathan N.
    National Instruments

  • LabWindows/CVI Remote User Interface

    I have an application that I would like to modify to enable running the User Interface Panel from a remote
    computer. I have found articles on doing this with LabView. Can this be accomplished using LabWindows/CVI 7.0/7.1 ?

    Hello Hornsbyr,
    It is possible to have run remote front panels in LabWindows/CVI. First you would need the CVI Enterprise Connectivity Toolkit as an add on to 7.0 or 7.1. A web server is included in the Enterprise Connectivity Toolkit. By setting up and connecting to the web server, you will be able to monitor and control the operation of your front panel through a web browser. The INET_RegisterPanelAutoUpdate function is used to export a LabWindows/CVI user interface panel onto the Web. Once a client requests the image of the panel, the server periodically sends an updated image of the panel.
    The image of the user interface is sent as a JPEG image, but as stated in the LabWindows/CVI Function Help, the JPEG will not include your UIR's menu bar, title bar or borders.
    I have attached a document that further describes how to control your front panel remotely.
    Also, here is a link to the product pricing sheet: http://sine.ni.com/apps/we/nioc.vp?cid=11128〈=US
    Wendy L
    LabWindows/CVI Developer Newsletter - ni.com/cvinews

  • Hide disabled executions in Teststand 4 Operator interface?

    Hi:
    I'm customizing the Teststand 4 Full Featured CVI Operator interface.
    When running in the Batch model, we often run on less then the full number of test sockets indicated in our model options.
    In this case, the unused test sockets show up as disabled executions in the operator interface.
    Is it possible to hide the disabled executions?
    Thanks,
    Dave

    Hi:
    I was working on the batch model TileWindows changes in parallel and had noticed the tracing problem as well. The TileWindows subsequence from your BatchModel fixes this problem - thanks.
    However, I'm able to reproduce a run time error through a sequence of (perhaps unlikely) events:
    * start a test sequence with 4 test sockets using the batch model
    * run the first socket, terminate in PreUUT, don't restart the first socket
    (only the initial TestUUTs execution plus socket 0 will be visible in the operator interface, as expected)
    * run the second socket, terminate in PreUUT, don't restart the second socket
    (only the initial TestUUTs execution is visible in the operator interface)
    * run the third socket, terminate in PreUUT: run time error popup:
    Execution is already closed. Not found in list of executions
    Operation Failed. [Error Code: -17500]
    I'm assuming this has to do with the PreUUT call being before the TileWindows call. Suggestions on how to get around this error? Do I need to force all socket windows back open before the TileWindows call to catch this condition?
    Thanks,
    Dave

  • Is it possible to step into a CVI dll when called by TestStand?

    As the question says: "Is it possible to step into a CVI dll when called by TestStand?"
    I am sure Ray F. may have a few tricks up his sleeves...  Hope you see this post, Ray!
    I compiled a dll using CVI.  The dll is called as a test by TestStand.
    I do have an "exe" version of the code that I use for debug with a testbed, but the behaviour is not the same as testing the actual target while running TestStand.  My goal is to get as close as possible to the real events.
    Thanks,
    JLV

    Sorry about that,
    There are two ways as I was saying:
    1. You can configure the CVI adapter to Execute Steps in a External Instance of CVI (requires CVI 6.0 or greater).
    Only go to Configure->Adapters and select the LabWindows CVI adapter and click on configure and select the corresponding option.
    After that set a break point in the step that you want to debug.
    An external instance of CVI will be launched where you can set break points and step into the code.
    2. From CVI Specifying an external process:
    In CVI go to Run Specify External Process and enter the seqEdit.exe as the program name (you have to browse to the location <TestStand>\Bin\SeqEdit.exe).
    As the argument you enter the name of the sequence file you want to debug.
    Now just select Run->Debug SeqEdit.Exe
    The Sequence Edtior will be launched and you can set break point in your CVI code and step into it when the step is executed.
    Check the Using LabWindows/CVI with TestStand reference manual for more information.
    I hope it helps you to get started.
    Regards.

  • How to access the result list in teststand after execution using labwindows​/cvi

    I am developing a user interface in labwindows/cvi that runs multiple teststand sequence files and would like to combine their reports (generated in teststand) into a single file at the end of a UUT. What is the best way to do this? At the moment, I'm trying to access the result list local variable after the execution has ended using API calls from labwindows/cvi and an end-of-execution callback event but those run-time variables do not exist anymore. How do I get a hold of the result list array at the end of an execution? I would like to grab this variable and pass it along from sequence to sequence using labwindows/cvi and not teststand itself. Is this possible? Any help would be great.
    Thanks in advance,
    Luis

    Hey Luis,
    Check out the response to this thread at the NI TestStand board here!

  • Retour paramètre string par Labwindows/CVI pour Teststand

    Bonjour à tous,
    j'utilise Teststand 2012 Development System et Labwindows/CVI 2012 Development System sous Windows 7 professionnel.
    Le contexte : grâce à une DLL crée avec Labwindows/CVI j'appel la fonction "Traitement" par TS.
    Le prototype de la fonction est le suivant void __declspec(dllexport) Traitement (char message[256], car reponse[256]);
    Je passe en paramètre deux strings à cette fonction. Cette fonction reçoit un "message", effectue un traitement sur celui-ci et le renvois sous le tableau "reponse" à TS. Cette fonction a été testée et fonctionne sous CVI.
    Mon problème : J'ai vérifié ma fonction reçoit bien le message mais me retourne quelque chose d'erroné( cf. image) et n'est censé me retourner, dans"reponse", que les chiffres au début mais me rajoute des instructions en temps que string. Je ne comprend pas comment cette suite d'instruction ce rajoute et pourquoi?
    J'ai consulté tous les messages disponibles sur le forum et je n'ai pas réussi à trouver un problème équivalent et donc une solution.
    J'espère que vous aurez une idée, voir pourquoi pas une solution
    Dans l'attente d'une réponse,
    Cordialement,
    Erwan.
    Résolu !
    Accéder à la solution.
    Pièces jointes :
    message.png ‏74 KB

    Bonjour Akagi,
    Dans une chaîne de caractère, "Null" ou "\0", correspond effectivement à une fin de chaîne.
    Pour éviter ce comportement, vous pouvez changer le type de passage de paramètre dans TS en tableau de Numérique.
    Ce faisant, aucun traitement ne sera fait sur le caractère "NULL". pour rappel un char = 1 Octet, on peut donc utiliser un tableau de numérique U8 pour représenter une chaîne de caractère.
    En résumé, si votre chaîne de caractère = 3"Null"01, vous obtiendrez ainsi: tab[0] = 3, tab[1] = 0, tab[2]=1.
    Je suis désolé, mais j'ai du mal à saisir où est intégré le caractère "NULL" dans CVI, est-ce une entrée clavier saisie par l'utilisateur, autre?
    Est-il possible d'utiliser un autre caractère ou série de caractère(non spécial) permettant d'identifier cette transition/caractère spécial "Null"?
    EX: (\) = "Null", soit la chaîne 3(\)01 équivalent à 3"Null"01. Il suffit ensuite d'établir un algorithme permettant de changer (\) en "NULL".
    Cordialement,
    Rémi D.
    National Instruments France
    #adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
    >> Les rencontres techniques de NI - Mesures et acquisition de données : de la théorie à la mise en ...

  • Debugging Labwindows dll in teststand with CVI 9.1.1

    Is there a known problem when debugging Labwindows DLL used as Teststand Code module ( using the Labwindows CVI Adapter)?
    My setup includes to powersupplies with IVI instrument drivers ( Agilent 6032A and and E3634 A) a a few other instruments with non-IVI instruments drivers. When start CVI, load the dll project and then start the Teststand Sequence editor as program to be debugged an then step into the C-Code it looks like there is process that watches both powersupplies and tries to reset them again if I access them from my C code through the instrument driver. There is no such effect with the non-IVI instruments and also if I run the code outside the debugger there is no such effect.
    Any Ideas whats going wrong here ?
    Solved!
    Go to Solution.

    some more information. I#ve updated now to CVI 2010 and the effect still exists. To demonstrate it I've attached a NI SPY log. The 6032A lives at GPIB ID 3 the E3634 at GPIB ID 5. I'am running the following code:
    Fmt(resource_id,"GPIB::%d::INSTR",addr_PS_P24V);
    tsErrChk(status = hp6xxxa_init (resource_id, VI_ON, VI_ON, 2, &Instr_Handle_PS_P24V));
    // Export Instrument handle for PS_P24V
    tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo,
    "FileGlobals.Instr_Handle_PS_P24V", 0x1,
    Instr_Handle_PS_P24V));
    //set limit voltage and current
    // status = hp6xxxa_603xA_soft_limits (Instr_Handle_PS_P24V, 30, 0.5);
    tsErrChk (status = hp6xxxa_603xA_fold (Instr_Handle_PS_P24V, 0));
    //set voltage and current depending on device A/AP 10A B/C 11.5 A
    if ( is_ALA_B_device( testData->seqContextCVI) || is_ALA_C_device( testData->seqContextCVI) )
    tsErrChk (status = hp6xxxa_volt_curr (Instr_Handle_PS_P24V, 26.0, 11.5, 1));
    else
    tsErrChk (status = hp6xxxa_volt_curr (Instr_Handle_PS_P24V, 26.0, 10.0, 1));
    tsErrChk (status = hp6xxxa_delay (Instr_Handle_PS_P24V, 0.500, 1));
    Delay(.2);
    //output off
    tsErrChk (status = hp6xxxa_output_onoff (Instr_Handle_PS_P24V, 0, 1));
    Delay(.2);
    [... later for the E3634]
    // Get GPIB-Adress of PS_P3V3
    tsErrChk(TS_PropertyExists(testData->seqContextCVI, &errorInfo, "FileGlobals.GPIB_ADDR_PS_P3V3", 0, &propertyExists));
    if (propertyExists)
    tsErrChk (TS_PropertyGetValNumber(testData->seqContextCVI, &errorInfo,
    "FileGlobals.GPIB_ADDR_PS_P3V3",
    0, &GPIB_ADDR_PS_P3V3));
    addr_PS_P3V3 = GPIB_ADDR_PS_P3V3;
    #ifndef NO3V3 // NO 3.3V programmable source on TK2
    // Initialize PS_P3V3
    Fmt(resource_id,"GPIB::%d::INSTR",addr_PS_P3V3);
    tsErrChk(hpe363xa_init (resource_id, VI_TRUE, VI_TRUE, &Instr_Handle_PS_P3V3));
    // Export Instrument handle for PS_P3V3
    tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo,
    "FileGlobals.Instr_Handle_PS_P3V3", 0x1,
    Instr_Handle_PS_P3V3));
    hpe363xa_ConfigureOutputRange (Instr_Handle_PS_P3V3, "",
    HPE363XA_VAL_RANGE_VOLTAGE, 5);
    hpe363xa_ConfigureVoltageLevel (Instr_Handle_PS_P3V3, "", 3.3);
    // Output off
    hpe363xa_ConfigureOutputEnabled (Instr_Handle_PS_P3V3, "", VI_FALSE);
    hpe363xa_ConfigureCurrentLimit (Instr_Handle_PS_P3V3, "",
    HPE363XA_VAL_CURRENT_REGULATE, 0.5);
    hpe363xa_ConfigureOVP (Instr_Handle_PS_P3V3, "", VI_TRUE, 4);
    #endif
    #ifdef TK3 // use E3640 powersupply for TK3
    Fmt(resource_id,"GPIB::%d::INSTR",addr_PS_P3V3);
    tsErrChk(hpe364xa_init (resource_id, VI_TRUE, VI_TRUE, &Instr_Handle_PS_P3V3));
    // Export Instrument handle for PS_P3V3
    tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo,
    "FileGlobals.Instr_Handle_PS_P3V3", 0x1,
    Instr_Handle_PS_P3V3));
    hpe364xa_ConfigureOutputRange (Instr_Handle_PS_P3V3, "1",
    HPE364XA_VAL_RANGE_VOLTAGE, 5);
    hpe364xa_ConfigureVoltageLevel (Instr_Handle_PS_P3V3, "1", 3.3);
    hpe364xa_ConfigureCurrentLimit (Instr_Handle_PS_P3V3, "1",
    HPE364XA_VAL_CURRENT_REGULATE, 0.5);
    hpe364xa_ConfigureOVP (Instr_Handle_PS_P3V3, "1", VI_TRUE, 4);
    // Output on
    hpe364xa_ConfigureOutputEnabled (Instr_Handle_PS_P3V3, "1", VI_TRUE);
    #endif
    If you look into the Spy Log you will see at #241 the first hit of that strange process, which beginns with a viOpenDefaultRM
    and ends with a viClose at #252
    after issuing an *IDN?, which fails because the 6032A doesn't support *IDN?. Then the first driver call ( init function) can be identified.
    later on , when the code goes to the E3642 using ID5 at #1142 in SPY log you will see that the strange process will finally send a *RST if the *IDN? succeeds.

  • Passing a struct from TestStand to LabWindows/CVI

    I am passing a struct to a dll written in CVI.
    Here is the problem: The code is written in CVI (c code) if I use "struct MyStruct *MyData" as the parameter definition in the dll TestStand works fine. But if I define my struct using a typedef (i.e. typdef struct MyStruct) then use MyStruct *MyData as the parameter TestStand throws a warning. 
    I an using the C\C++ adaptor.
    It is too late in the programming effort to go back and remove the typedef.
    So, how do I get TestStand to accept the typedef?
    Thanks
    Carmine
    Solved!
    Go to Solution.

    In ANSI C, the struct names and type names belong to separate namespaces. You can declare structs several different ways:
    1) struct structName { int x; };
    2) typedef struct { int x; } typedefName;
    3) typedef struct structName { int x; } typedefName; // Note: structName can be same as typedefName.
    I'm assuming you are using the 2nd example above in which case LabWindows/CVI automatically generates a struct name (something like __unknown_1) that Testand uses.
    Although you said it is too late to remove the typedef, can you add a struct name as in example 3 above? You can use the same name as the typedefName and TestStand will recognize it.

  • Testand will not convert my labWindows CVI sequence file to a TestStand sequence file.

    Testand will not convert my labWindows CVI sequence file to a TestStand sequence file.
    Attachments:
    ACC3.squ ‏3 KB

    If you are using an older version of the CVI Test Exec toolkit, check with your local Field Sales rep to see about getting the necessary software to use for temporarily upgrading your existing Test Exec sequences to version 2.0 for migrating to TestStand.

Maybe you are looking for