TestStand LabVIEW OI and modelsupport2.dll

I'm trying to understand how to do some customization of the LabVIEW version of the TestStand (3.5) Operator Interface. I need the default OI to change in several areas. One in particular is that a teamate company (dictating the look and feel) wants us to have a Data Entry dialog. They say that it's part of the TestStand Sequential Process Model and it's contained in ModelSupport2.dll, and that it contains its own GUI that is used by the process models.
I hope to develop tests in LV8. As a first step, I'm trying to understand how (and when) to call the functions within the modelsupport2.dll. I there any documentation on the functions within (other than the .h)? Can someone walk me through an example where a sequence file (or is the call made from LabVIEW?) displays some dialog that is supposedly in modelsupport2.dll?

There's several dialogs in modelsupport2. There's the serial number dialogs for the sequential model, parallel model, and batch model. The only other dialogs are for the report file options and model options. The last two are what you get when select Configure>Report Options and Configure Model Options. The serial number dialogs are called in the process model like the other company said and I don't know of any test sequence or OI that would call them directly. If you want to override them and use your own serial number dialog, then you can put own callback in a sequence.

Similar Messages

LABVIEW 2009 and lvanlys.dll

Hi,
I'm relatively new to LABVIEW and I'm building an application with LABVIEW 2009. The application works well on my PC. However, the application is
intended to be ran on another machine. I then tried two approaches. First, I copied the executable file onto the second machine and second, I created
an installer file. Both methods resulted in an error when the executable was ran on the second machine. Here is the error:
"Missing external function lvanlys.dll Mean_Head.C in VI NI_AALBase.lvlib:Mean.vi". I'm hoping anyone out there knows the solution to this.
Thanks!
Bobby C

I'm not sure that link is appropriate since it talks about LabVIEW 7.1 installer and windows NT.
For LabVIEW 8 or higher, make sure that the data folder is part of the install. Done correctly, there will be your application, the data folder, and in the data folder, lvanlys.dll.

Using ModelSupport2.dll in LabView without TestStand

I would like to use the ModelSupport2.dll purely in a LabVIEW environment as either by a "Call Library Function Node" or "Active X" or ".NET" without using TestStand.
In particular I would utilize the the "DisplayPassBanner" and "DisplayFailBanner" functions. I want the banner pop-up's so I can provide a consistency between applications that don't use TestStand and those that do.
The DLL call requires a numeric input "context" which I am not sure what it needs for a reference number.
In teststand it is passed an "Object", "CVI Active X Automation Handle", "By Value" from the "ThisContext"
How replicate this or create equivalent in LabVIEW
Any suggestions appreciated
A

A,
if you are looking into the sources of ModelSupport2.dll (the sources are included as LabWindows/CVI project and the needed C files), you will see that the display banner functions do access the object referenced by the parameter 'context'. The context is a reference to the dataset of a running TestStand execution when called from the TestStand process model.
So it will not be possible to use those functions if you are not going to use TestStand/running an actual sequence.
There are, however, two ways you can go for:
a) Design a LV VI dialog such way that it looks like one of the banner and call it as a subVI.
b) Use the LabWindows/CVI sources of ModelSupport2.dll to copy the banner dialogs into a new CVI project (from modelpanels.uir) and create similar functions into a custom written dll which do not require the ActiveX handle 'context' to be passed.....
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

TestStand Test Environment adapter dll error and Type Palette error

I am new to TestStand and I am having a problem opening a TestStand 3.1 standalone UI application. The UI was built a couple of years ago and others use it within my company without problem. I however get the 3 .DLL adapter errors and the Type Palette errors shown below when I try to open it and I can't figure it out. I have tried everything from uninstalling and reloading TestStand 3.1 and uninstalling the UI application and reloading and it did not fix the problem. I verified that the errored .DLL's are present in the Bin directory and the Type Palette files are present in the Type Palette directory. I asked other more experienced TestStand developers within my company if they have ever seen this or knew what was wrong and they can't explain the errors either. Any suggestions?

Cole - There are probably many differences between my machine and that of my counterparts but they have told me that the only thing I should need to run this standalone TestStand GUI application is TestStand 3.1 and Microsoft .NET Framework which I do have.
The standalone GUI application is a common front end application that we use for a large part of our production testing at my company. It allows us to have a GUI based front end to our TestStand sequences for running testing in a production environment so the operators can see the test running step by step on the screen. We have the GUI application installed on multiple different Production machines (probably over 10) and all are different machines with different software installed on each. the only real common aspect between them that we ensure is that they all have TestStand 3.1, the GUI application, and .NET Framework installed.

TestStand with perl and Tcl examples need newer dlls

I'm trying to run the TestStand with perl and tcl examples but they both point to older dlls. When I try to update by making changes and recompiling the main.cpp in VC++ 6.0, I get errors referencing cl.exe and oleauto.h, I'm not sure if I missed a step or what. See attached screenshot. TIA. Judy Jiru
Attachments:
scrnShotErrors.doc ‏110 KB

Hey Judy,
From my understanding oleauto.h and cl.exe are not National Instruments files. My suggestion would be to google the files - I found a bunch of hits for both the files. It may also be helpful to post on a discussion forum dedicated to VC++ 6.0. You may want to try the Microsoft newsgroups or I'm sure there are tons of other online.
I hope this helps! Once you compile the dll if you have problems calling it from TestStand please post back.
Regards,
Sarah Miracle
National Instruments

Crash in application by using TestStand 4.0 and CVI labWindows 8.01

Our application often crashes in two areas:
1) Often crash in the case:
    During running, if there is poop, like error message, you want to debug by opening other programs,like notepad.
    It shows error signature:
    AppName: operator Interface.exe     AppVer. 4.0.0.326, ModName cvirte.dll
    ModVer: 8.1.0.271         Offset : 000b9c8a
2) Often crash at the end of test, when generating TSV file.
     AppName: operator Interface.exe     AppVer. 4.0.0.326, ModName msvcr80.dll
    ModVer: 8.0.40727.762       Offset : 00008a8c
We use TestStand 4.0 and CVI LabWindows 8.01. The program is running in our customized operator interface.
But I tried using the default TestStand operator interface, it crashed too.
Also we found it is related PC too. One PC in our lab crashed often, but it actually newer PC with bigger RAM. (Pentium(R) 4 CPU 3.2GHz), 3.19GHz, 0.99 GB of RAM)
The one crashed Less often is Pentium(R) 4 CPU 2.80GHz, 2.79 GHZ 504 MB of RAM.
Hope you can help us to find out root cause.
Thanks

Hi Doug,
Thanks for your reply.
Answers to your queries:
1. We are not calling any DLLs from our sequences.
2. We are only using LabVIEW modules and the VIs are called under LabVIEW development environment and not using Run Time engine.
3. In our case it is always seqedit.exe which crashes. LabVIEW never crashed. Hence I think its TestStand whose memory is getting corrupted.
We are trying to narrow down the issue as suggested by you.
By the time, we have observed a strange thing while the sequence editor crashed.
In our sequence we call a thread which calls a VI to run continuously and collect the data from other modules.
What we observed is that, when the sequence editor crashed (the popup appeared), it was still executing the sequence (running a loop). I was able to break the execution and debug it. All the variables were also having proper values.
But the VI which was running in a separate thread was in surprising state. That VI was showing as executing but actually it was not running any of its code. I tried to put probes inside that VI but they were not updated (meaning that part of code was not runnning). I tried to stop the VI using the abort button but no help. It was not having any effect. I also clicked on the Pause button. The button turned red but the VI didn't halt at any part of code (actually the VI was not at all executing). An other VI which was called by another thread was working properly. I could see it by putting probes in that VI.
If your thought about the memory corruption is correct, is it possible that this VI is somehow corrupting the sequence editor memory?
I am not sure, but I think wherever the sequence execution may be, but the above mentioned VI is always in this state at the time of crash.
I tried to reproduce this scenario locally but it ran without problem for hours
Probably I am still not able to properly reproduce it. I'll work on it further and let you know the outcome.
Regarding your last question, We are using LabVIEW notifier. A VI is called which waits on LabVIEW notifier from another VI. That code is pretty simple it just obtains a notifier and waits on it indefinitely.
Please let me know your views on the above mentioned issue.
Thanks,
- Kaustubh

Modelsupport2.dll changes don't take affect

Running TestStand 4.0 and LabWindows/CVI 9.0.1.
Followed instructions per http://digital.ni.com/public.nsf/allkb/A6D0EF1F4FE5EC94862570AE000CE374 to change my test socket numbers to be non zero based for batch model. Also modified paralleluutdlg.c to increase the MAX_NUM_TEST_SOCKETS_VISIBLE 6 (used to be 5).
The modelsupport2.dll compiled successfully, but the changes do not occur when I run my sequence file using the batch model; i.e., the test sockets still start from 0 instead of 1 and the number of visible sockets is 5 and not 6.
I checked the configured search directories and the user components directory (containing my modified files) is ahead of the default NI components directory as desired.
Am I missing a required step here?
Thanks!
Solved!
Go to Solution.

Hi George,
The KnowledgeBase article you are referring to is for the parallel model, not the batch model. However, if you open the batchuutdlg.c and search for the same line of test as described in the KB and add "+1" to it, it should work. I have confirmed that it works on my end. Just to make sure this is clear, this only changes the dialog box and will not change the numbering in the process model. Changing that numbering requires a much more extensive effort.
Regarding the MAX_NUM_TEST_SOCKETS_VISIBLE 6 change, I have also done this and it does show 6 visible batches in the dialog box. Please keep in mind that you need to just replace the number without changing the spacing on the line. You will also need to go into Configure->Model Options and change the Number of Test Sockets to 6 to ensure that you see the 6 visible batches. Changing this will cause the window to expand over the "Go" and "Stop" buttons so there will have to be more extensive changes to move those buttons down. I hope this helps address your question!
Regards,
Jackie
DAQ Product Marketing Engineer
National Instruments

Switching modelsupport2.dll

We are using sequences running with batchmodel with a modified modelsupport.dll i teststand user directory, because we usually need an additional entry an additional partnumber for each UUT and overriding pre UUT callback doesn't work well in batchmodel.
Now we have one type of UUT without that additional partnumber. Is it possible to make the sequence for that UUT using the "standart" modelsupport2.dll in installation path even if there is the modified modelsupport2.dll in teststand user ?

Hi mkossmann,
as far as I know modelsupport.dll is part of the process model. Thus I guess you have also 2 process models. In the following link you'll find an instruction to change the process model:
How Do I Specify a Particular Process Model for a Specific Sequence File?
http://digital.ni.com/public.nsf/allkb/CEDEDEB004083D6F862572B400779E46?OpenDocument
I hope this helps.
Kind regards
Heinz

Teststand deployment build fails with dll dependency

Hi guys,
I am struggling with test stand deployment for 3 days. hope somebody can help. ( I am using teststand 4.0 nd labview 8.5 and .net 2.0)
I have sequence files, with many subVi' s and .net assmeblies with dependancies, added to workspace , and when i run the sequence file, it works fine.
Specifically, the sequence file calls many Vi's, some of which use the .net assembly from "C:\program files\National instruments\labview 8.5\use.lib" ( and not specifically from the folder where the Vi resides), and still it works.
However, when i build ths same using deployment utility (figure 1), these assemblies and other go to "\\installation directory\data" and the build fails(figure 2), as the "property node " for the .net assembly( build using c# public static class) gets invalid( figure 3).
Figure 2:
Figure3:
Now, the same VI in different folder ( C:\development...) is able to reference the assembly from "C:\program files\National instruments\labview 8.5\use.lib"( I had added the refernce from labview project initially from different location, but after copying the file to this location, VI's still worked) and works fine (figure 4).
Figure 4:
I have tried adding "\\installation directory\data" Teststand search directory, but no luck.
I have following questions:
is it manadatory to keep the dl's and their dependencies in the same folder, in which VI's use them, for sucessful build through deployment ? if yes, by default, these would go to "\\installation directory\data", which is different from "installation directory\...VI directory\ , and would not work still?
it is mandatory to add the VI's that use .net assemblies to labview project, for sucessful deployment? if yes, how do we add a labview project to testsand workspace?
If the assembly can be added to Global assembly cache, would this solve the problem of 'unsucessfull build" of installer , and even if it does, how can (a) I add the assembly to GAC on development system (b) make sure that installer installs the assembly to GAC on deployed system (through deployment utility)?
other than above, does anybody have other solution to my problem?
I am already late for deployment of project to customers, and need immediate help.
Thanks
vivu

Hi Jon.
Thanks for replying. The .net assembly was created in visual studio, by different engineer. I tried using 'c:\prog fil\nat inst\labview 8.5\user.lib' as the source path, and keeping destination to (1) \\target\data (2) \\target\subVI location that uses this assembly (3) \\lNI directory\\labview8.5\user.lib.
all of thse did not help.
Anyways, I asked my colleague to change the .net assembly, so that one of the VI that was using property node, now, just uses 'invoke node" ( and source dll was changed by using c# method instead of property to achive same result)n and then, I rebuild the deployment choosing source and deployment paths as above. none of them worked, except when i choose deployment to be "\\target\subVI" location that uses this assembly .
So, this works and I was satisfied. However, after deploying, I run into strange problem.
( pleas note that I just created 1 seqeunce file out of 5, that are part of the worskpace,rest everything was done by a guy 8 years back, and although I am well versed with labview, teststand is new to me).
When I run the test on bhild machine, before any of the sequence file executes, a dialog box opens as below:
Once thse values get populated, then steps in the chosen sequence file execute. I found that this is done by a VI , that might be called by some of the sequence file or by some Testsand directory( which I don't know , as I did not create it). Vi is shown below:
However, when i deploy the test, on the deployment machine, as I run the test, it does not complain about any missing .dll or broken VI's, but the dialog box disappears, just does not come up.
As you can see, the only thing i changed from previous deployment was adding following files in deployment : zoundshearingnet.dll and commifnet.dll for the .net deployment, and I do not beleive this should change the VI/VI call that loads the dialog box at the start.
I am also exporting the station globals and testexec.ini files as below:
however, I do get warning in deployment:
So, I have the following questions:
1) does this warning have anything to do with the missing dialog box?
2) as I understand, the VI that flashes the dialog box at the start, use "sequence context" and then "start modal dialog". I tried running the test on build machine, and pasue it, and then, run this VI. it fails on "start model dialog", but that could be because perhaps I am not supoposed to run ot this way? is there a way I could debug this Vi with teststand?
3) Can i know, how is this VI called by testand and who calls it? If i start opening each sequence file, which have hundeders of VI's and subVI's, it will take me hours to do that.
4) so, basically, the problem is that when a sequence is run, a VI interacts with the sequenec and opens a dialog, which after deployment . fails to do so. are there any such examples that i could refer to, to help me understand how this works?
Thanks
vivu

I just installed LV2011 and one dll from my vi won't load with the error "application configuration is incorrect"

I just installed LV2011 and one dll from my vi won't load with the error "application configuration is incorrect", which is Windows lingo for "missing package dependencies". All the computers at my company with 2010 loaded seem to do OK. When I do a Dependencies Walk I get missing Visual C debug dll's missing plus IEshims and wer which both have a whole tree of dependencies missing on my machine. The Windows install is the same "Windows XP version 2002 Service Pack 3" on my PC and the working PC's. So I'm thinking I have to uninstall 2011 and go back to 2010. Is this correct? Those VC debug dll's were installed on the machines with 2010 in them but were not installed in mine.
I've heard the advice to recompile the dll with debug turned off but I don't have access to the source code.
Thanks in advance.

u87 wrote:
Thanks for the reply. This at least tells me that going back to LV2010 is not likely to solve the problem. The missing dll's are:
MFC90D.dll
MSVCR90D.dll
IESHMS.dll
WER.dll
And, once again, IESHMS and WER have other dependencies. So perhaps i need to install the Visual C++ development environment.
IESHIMS.dll is an Internet Explorer DLL that gets usually delay loaded by shdocvw.dll. As delay load it can not cause DLL load errors but only runtime errors. Maybe your DLL has it as direct dependency but that is unlikely since it does not have a documented interface.
WER.dll is Windows error reporting for Vista/Win7.
MFC90D.dll is the Microsoft Foundation classes and MSVCR90D.dll is the MS C runtime library, both as debug variant.
So all the DLLs you mention are actually MS DLLs! You haven't identified the DLL that you try to access in LabVIEW that causes these error messages. IESHIMS and WER are usually delay loaded by any component that needs it and should not likely be used by non MS code.
What is the DLL you try to load into LabVIEW and by whom? Get the provider of that DLL to provide you a non Debug build of the DLL. Installing Visual C on all the machines just to make the DLL load is not a solution, besides that it is likely not legal since I doubt you have that many licenses.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Error while using LabVIEW 8.2.1 Dll from Visual C++ 6.0

I am getting an error while using a LabVIEW 8.2.1 dll from Visual C++ 6.0 application. This is what I am doing:
1) Created a dll using LabVIEW 8.2.1 (I used a tutorial from NI knowledge base: "Creating DLLs from 6.0i". It is a temperature conversion VI; input DegreeF and get DegreeC out). Instead of LabVIEW 6.0i, I used 8.2.1. It created the dll Convert_Temp.dll successfully.
2) Then I created a Visual C++ 6.0 application (used a tutorial from NI knowledge base: "Calling a DLL from Microsoft Visual C++ that was Generated by LabVIEW 6i). I could build the project and create an executable application F_To_C.exe.
3) Then copied the LabVIEW dll Convert_Temp.dll into the folder where F_To_C.exe resides. Using windows explorer, went into that folder, and executed the application. I got the following error:
System Error 998 while loading the LabVIEW run-time engine (C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\8.2\lvrt.dll).
Convert_Temp requires a version 8.2.1 (or compatible) LabVIEW Run-Time Engine. Please contact the vendor of Convert_Temp to correct this problem.
I checked the folder: C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\8.2\. It has the file lvrt.dll.
So why am I getting this error?
GKB

sounds like you need to install the LabVIEW 8.2.1 runtime. Not the 8.2 runtime engine.
Paul <--Always Learning!!!
sense and simplicity.
Browse my sample VIs?

Labview hangs when accessing dll

Im accessing an active x dll using labview 8.21. When we query the dll all parallel loops in labview hang until the dll returns. Is there a way to get around this behaivour?

HI,
I do not know if this will help, but there is an issue with the Call Function Library node in LabVIEW 8.2.1 and is posted in the LabVIEW 8.2.1 Readme help here:
If you configure a Call Library Function Node to call a LabVIEW DLL, place a checkmark in the Specify path on diagram checkbox on the Function page of the Call Library Function dialog box, and select Run in UI thread in the Thread control, LabVIEW hangs when executing the Call Library Function Node. To correct this problem, select Reentrant instead of Run in UI thread in the Thread
control. If you configure the Call Library Function Node to call a DLL
written in C with these same settings, LabVIEW works correctly.
I hope this helps,
Regards,
Nadim
Applications Engineering
National Instruments

Data access in Teststand/LabVIEW through OPC connection

We are using TestStand 2.0 and LabVIEW6.2 and following problem occurs when accessing the datas from UUT through OPC.
For the first UUT i get the measurement datas but starting the next UUT causes a system hang up. The corresponding LabVIEW VI stops at the connect to the OPC Server it doesn't read the selected item. Only with LabVIEW there is no problem launching OPC data access for multiple times. Does anyone have expierence with this configuration: TestStand-LabVIEW-OPC?

For your information, there is a new TestStand Add-on "OPC DA Connect" which adds a StepType Palette dedicated to OPC Data Access.
You can configure each step by browsing the OPC servers on your network and browsing variables within these servers.
This toolkit has free deployment licence.
Hoping this helps.
Jean-Louis SCHRICKE
├ CTA - Certified TestStand Architect (2008 & 2010 & 2014)
├ CTD - Certified TestStand Developer (2004 & 2007)
└ CLD - Certified LabVIEW Developer (2003 & 2005)

LabView TEDS library into DLL or ActiveX Control so that I can use it in C or Visual Basic?

We are developing software in LabWindows/CVI and Microsoft C. I heard that LabView can generate DLLs. Can I turn LabView TEDS library into DLL or ActiveX Control so that I can use it in C or Visual Basic development environment?

Technically what you are proposing is possible with LabVIEW. With LabVIEW's application builder, VIs can be built into dlls. Also, LV has ActiveX hooks and so you could create a system for calling into it from CVI. However, this is not what I would recommend.
The LabVIEW VIs have been written to a preliminary version of the IEEE specification (1451.4) that describes the TEDS data which is primarily why I'm advising you against using them. Once the IEEE spec is approved (the current timeline is currently late March), it will become public and you can write your own code according to the specification (or wait for someone else to write it). To help you get started, the spec includes flex and bison code that describes the syntax and structure of the template files
Internally, we've written some C, C++ and Java code to the preliminary version of the spec and we've found that we can duplicate the functionality of the TEDS Library for LV in roughly 2 weeks in any other language.

What are analogous shared libraries that can be called using a call library function to user32.dll and lvtoolbox.dll when using Linux and Mac?

I am wondering if anyone is familiar with how to get similar information with a LV program using a Linux shared library as well as the corrolate Mac library to the Windows user32.dll and lvtoolbox.dll. I specifically am trying to get system metrics such as screen resolution information and cursor information as well as being able to set mouse position. I am trying to convert a LV Windows program to these other operating systems and I am unfamiliar with these platforms.
Thanks for your time - I really appreciate it.

There is no simple answer to that. On Linux you will likely have to call into X Server, which would be a pain to do, due to various versions and implementations of that. On the Mac there would be the difficulty that you can't call into the native ObjectiveC API but would need to find a Carbon API or something like that to do what you want.
If you seriously want to do something like this for multiplatform, you should bite the bullet and start coding an intermediate shared library in C. This library would export a LabVIEW friendly C API and access whatever system API you need to have for the particular functions. But multiplatform programming on this level is a pain in the ass, no matter what.
Message Edited by rolfk on 04-21-2010 08:26 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

TestStand LabVIEW OI and modelsupport2.dll

Similar Messages

Maybe you are looking for