LabVIEW VI causes TestStand Deployment to fail

Hello,
I have a problem with the attached VI. Any time I include it in a deployment, I get an Error that says "Internal Error Code 1 processing VIs... Installer not created due to an Error"
The VI and a simple sequence file are attached.
Attachments:
IsMyProcessRunning.vi ‏13 KB
ProcessTest.seq ‏5 KB

Simon,
The following (below) is the Deployment improvements for TestStand 4.2. I haven't been able to look at the VI of the original post so I dont know of the actual problem but there are still issues with the deployment tool in TS4.2
Regards
Ray Farmer
TestStand Deployment Utility Improvements
The TestStand Deployment Utility now uses improved internal caching to accelerate analysis and build times. Additionally, the LabVIEW VI Options dialog box includes the following new options so you can choose between faster performance and improved error handling:
Check for Broken VIs During Analysis—When enabled, the TestStand Deployment Utility checks for broken VIs during analysis. This option is disabled by default to improve performance. Enable this option when you want to debug VI errors.
Check for Broken VIs After Build—When enabled, the TestStand Deployment Utility checks for broken VIs in the image directory when building an image. This option is enabled by default to ensure that distributed files do not contain broken VIs. Disable this option for better performance if you are rebuilding and have not made changes to VIs.
Remove Unused SubVIs—Removes unused polymorphic subVIs and disconnects type definitions when building. This option is disabled by default for backward compatibility. Enable this option for better performance and to deliver a smaller number of subVIs.
Note Enabling the Remove Unused SubVIs option disables certain editing and debugging options on the deployed system, such as wiring a new type to a polymorphic VI or making type changes across several VIs by editing a type definition.
The Deployment Utility also better integrates with LabVIEW 8.6.1 or later for improved build speeds and deployment of advanced LabVIEW features, such as VIs that include LabVIEW object-oriented programming.
The Installer Properties section of the Distributed Files tab of the TestStand Deployment Utility also includes a new Force File to Install option. Enable this option to force the installers the deployment utility builds to always overwrite existing files.
Refer to Chapter 14, Deploying TestStand Systems, of the NI TestStand Reference Manual and to TestStand Deployment Utility for more information about the TestStand Deployment Utility.
Regards
Ray Farmer

Similar Messages

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

TestStand Deployment problems with visarc issues

Recently I attempted to rebuild a TestStand Deployment that I had build just 1 month before and it wouldn't create the deployment. Changes that occurred between the last build and this build was an upgrade to LV 8.6.1 from LV 8.6.
The issue was that the file visarc was not able to be found by the deployment engine and wouldn't progress much beyond the tsw file verification. It turned out that having multiple versions of LV on my harddrive screwed up the linking on this file and caused the deployment to fail.
The following link solved the issue and allow the deployment to be built:
http://digital.ni.com/public.nsf/allkb/833BFD5E9CA0224886257584004DAA4C
I don't really have a question, just wanted to get this out there so fewer people have to sustain the pain that I went through.

Thanks for the input
Regards
Ray Farmer
Regards
Ray Farmer

TestStand Deployment Error Code 1055 when using LabVIEW Storage VIs

After a couple of days of playing with the TestStand Deployment. I final tracked down the VI that was causing this Error.
It was using thethe LabVIEW Storage VIs to save data to a TDM file.
My work around at the moment is to use a Wrapper VI and call this VI by reference.
That way the TestStand Deployment can't detect the Storage VIs.
I'm using LabVIEW 8.6.1 and TestStand 4.1.1 does anyone know if this issue has been address in TestStand 4.2?
Looks like the upgrade might be worth it.
Simon Holman
Software Engineer
Certified LabVIEW Developer
Certified TestStand Developer
measX GmbH & Co. KG.
http://www.measx.com
Solved!
Go to Solution.

Hi Simon,
I tested your sequence file in TestStand 4.2 and I didn't get any error! Which version of TestStand do you have? Can you post a screenshot of the complete internal error pop up?
Usually internal errors can be eliminated with the Clean Reinstall Procedure.doc, where you will remove all NI software and all references to NI software from your computer to start over with a fresh installation!
I hope these informations help you!
Best regards
Suse
Certified LabVIEW Developer (CLD)
Attachments:
Clean Reinstall Procedure.doc ‏32 KB

Issues with labview on TestStand deployment system (wont run without a labview License)

I am trying to deploy a system using testStand to a deployment machine for the 1st time. I have built my installer and image files etc.The files install successfully on the target machine however when I try and run my program in TestStand operator mode I have getting errors relating to Labview. The only way I can get around these error is to activate a Labview License on the deployment machine, this is not viable.
The error I see when I disable my Labview License simply states an error occurred accessing the Labview ActiveX automation server.
I have included the run time engines etc in my installer. As this is my first build is there something obvious I have missed here??
Thanks for any input.
Vinny
Solved!
Go to Solution.

Vinny,
my first guess is that the setting for the LV adapter on the deployment machine is still configured for "LabVIEW Development Environment". You have to change this to "Runtime Engine".
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Using LabVIEW Packed Library within TestStand Deployment Tool

I am wondering what could be the interest of generating Packed Library within the TestStand Deployment Tool since the sequences using these VIs will not be able to find the dependant VIs included into the build Packed Library on the deployment target.
Any experience using Packed Library within TestStand Deployment Tool ?
Jean-Louis SCHRICKE
├ CTA - Certified TestStand Architect (2008 & 2010 & 2014)
├ CTD - Certified TestStand Developer (2004 & 2007)
└ CLD - Certified LabVIEW Developer (2003 & 2005)

Jiggawax,
Sorry for the confusion,
My question concerns the developement of Custom Step Types.
For example, within a project or as an independant product.
The best practices is to avoid using main module when developing CST in order to preserve evolutivity (main module calling paramters are copied within CST instances and could need prototype updating). I prefer using PostStep (as NI does for its own CST).
Thus, when creating the CST palette, I have to configure the EditStep and the PostStep and define each VI call.
If I want to distribute these VIs through a .lvlibp, then I need to build a .lvlibp very early and use it within my CST palette.
This .lvlibp will be used on deployed benches and may not contain VI diagrams and debug options (best performance).
But during the development of my CSTs, if I need to debug the VIs called when using CST whitin a sequence, and if I don't want to change the called VIs defined in my CST palette, then I need to regenerate this .lvlibp with debug option (different from the deployment .lvlibp) in order to allow debug.
May be it could be interesting that the TestStand deployment tool take into account SubSteps when selecting the Packed Library option. This tool is able to modify sequences, it could be able to change also palette configuration file.
This will allow to have only two levels :
> Source and Debug (VIs)
> Deployment (.lvlibp)
instead of three :
> Source (VIs)
> Debug (.lvlibp with debug option)
> Deployment (.lvlibp)
Jean-Louis SCHRICKE
├ CTA - Certified TestStand Architect (2008 & 2010 & 2014)
├ CTD - Certified TestStand Developer (2004 & 2007)
└ CLD - Certified LabVIEW Developer (2003 & 2005)

Using LabVIEW RTE vs. LabVIEW ActiveX Automation Server (TestStand LVRTS) for a TestStand Deployment and experienceing Unabel to Launch LabVIEW.Application ActiveX Automation Server Error 18001

I am developing in TestStand 4.2.1 and LabVIEW 2009, I have accomplished the following:
1. Deployment package is built and deployed on PC
2. PC has activated TestStand Deployment License
3. LabVIEW 2009 RTE was selected as the adapter for the sequence and thus I believe the deployed testexec.ini contains this.
I am experiencing the following error: "see attachment".
Is the LabVIEW RTE the right selection?
Is there something I may have missed in building the deployment?
Do I need to register the ActiveX server.
THere seems to be conflicing solutions based on Version of TestStand and LabVIEW!!
Thanks!!
Attachments:
TS_LV ActiveX Error.doc ‏77 KB

Howdy mobiux,
Please consider KnowledgeBase 4V58058Z: -18001 Errors in TestStand. If you're using Vista or Windows 7, then this may apply as well. You might also consider ensuring you have the proper LV version active in the TS Adapter Options.
Warm regards,
pBerg

CSCse59177 - FWSM interface alias causes deployment to fail

   Presumably, this bug applies equally to the ASA-SM. If so, does anyone know if there any plans to provide a fix for it in any releases?

I have some more information on this problem.
The servlet fails because of its attempt to forward to the JSP.
I have discovered two things:
1: The code that causes the servlet to fail is given below.
     try
     RequestDispatcher disp = sReq.getRequestDispatcher(dest);
     if(disp != null)
          disp.forward(sReq,sResp);
     catch(Exception e)
     out.println("Exception! "+e);
where sReq is the HTTPServletRequest class representing the request, and sResp is the HTTPServletResponse class representing the response.
Commenting this code out seems to enable the servlet to generate output. If the code is left in, the J2EE RI seems to screw up in a manner described below.
2: Whenever the J2EE RI receives a "first" request for a JSP, it generates Java source code in a directory under the J2EE root directory: repository/myhost/web. Apparently, it then compiles this source code and creates a .class file in the same directory. Once the .class file is created, all is well because the RI can keep using that file.
Unfortunately, when a servlet attempts to forward to a JSP page, the J2EE RI apparently treats this forwarding as another new JSP -- even if the servlet is attempting to forward to an already- compiled JSP! Worse, the .java file it creates is a zero- length file. The zero- length file is not compiled; no .class file results. Even more funny, the J2EE RI also creates an empty directory whose name is the same as the servlet's alias!
The result, of course, is that no output gets generated.
This is looking more and more like a bug in the J2EE RI. Unless I am missing something.
Could someone please advise? This is a pretty serious problem!
-Factor Three

TestStand deployment utility crashes

Hi,
Trying to deploy a dummy test with the basics that will be used in production. It includes (all LabView) database access, report generation, DAQ control & GPIB IF and steps to exercise all to ensure it is working properly. In the editor, sequence runs fine, hits the database table with data, generates the test report and all that but...problem is when I go thru the deployment steps and use the deployment utility it crashes. Fast forward thru some debugging and head banging and I get to the root problem. I created a report class in LabView to handle the report tasks. The class control contains a class object reference to the actual report that is being generated. This reference is created using the New Report.vi that comes with LabView. Throughout the sequence I populate the report with the data I collect and print it as a pdf at the end. All this works great in the Dev environment for TestStand.
So now to the problem... when this report object is included in the class object it causes the deployment utility to error out with the following info from the log...
+++++++++++++++++++++++++++++++++++++++
Starting Analysis
Processing Workspace...
Workspace Processed
Finished Analysis
Building...
3:02 PM
LabVIEW Version: 10.0f2 (2010) (32-bit) English
Internal error code -2147023170 Processing VIs...
The remote procedure call failed.
in Dynamically Call Method in LLB - TestStand.vi:3->Dynamically Call Update Paths in Projects - TestStand.vi->Update LabVIEW Project Links - TestStand.vi->Package VIs - TestStand.vi->Build Create Image - TestStand.vi->Build - TestStand.vi->Distribution Wizard GUI - TestStand.vi->Deployment Utility Splash Screen - TestStand.vi
An installer was not created due to an error
The build is finished
3:06 PM
Aborted
+++++++++++++++++++++++++++++++++++++++
I have built a test sequence, LV project with a class object that has only 1 thing... the reference I mentioned above. With this config it still errors out. Next I deleted that object and put in class reference used in another part of the project and it completes the build as expected. I used the TestStand Workspace method in the deployment utility.
Any ideas? (hope that is enough info...)

OK, I included the folder with the report VI's in it and I get the same result. First build below is without the class object on the diagram,
2nd is with it. I tried a couple of things including adding the New Report VI to the diagram, same result.
+++++++++++++++++++++++++++++++++++++++
Starting Analysis
Processing Workspace...
Workspace Processed
Finished Analysis
Building...
1:49 PM
LabVIEW Version: 10.0f2 (2010) (32-bit) English
Making an installer, please wait...
Adding files to installer
Validating...
Copying files...
Scanning files...
Updating files...
Build complete successfully.
Done adding files
Preparing to build deployment
Copying products from distributions
Building deployment
Copying setup files
Setting merged database information
Setting product information
Setting developer part information
Starting final build
Validating...
Copying files...
Scanning files...
Updating files...
Creating merged database...
Creating installer files...
Build complete successfully.
Copying additional setup files
Compressing installer files
Done building deployment
The installer is finished
Loading product deployment information
The build is finished
1:52 PM
Warning: The installer does not include the following LabVIEW Run-Time Engine(s) required to execute VIs:
This Installer includes VIs compiled with LabVIEW 10.0.
+++++++++++++++++++++++++++++++++++++++
Starting Analysis
Processing Workspace...
Workspace Processed
Finished Analysis
Building...
1:53 PM
LabVIEW Version: 10.0f2 (2010) (32-bit) English
Internal error code -2147023170 Processing VIs...
The remote procedure call failed.
in Dynamically Call Method in LLB - TestStand.vi:3->Dynamically Call Update Paths in Projects - TestStand.vi->Update LabVIEW Project Links - TestStand.vi->Package VIs - TestStand.vi->Build Create Image - TestStand.vi->Build - TestStand.vi->Distribution Wizard GUI - TestStand.vi->Deployment Utility Splash Screen - TestStand.vi
An installer was not created due to an error
The build is finished
1:55 PM
Aborted
+++++++++++++++++++++++++++++++++++++++

Linker error during TestStand deployment

Using Version - LabVIEW 2014 and TestStand 2014
Test Stand deployment failed so I am trying to narrow down the issue.
Note:
1. Create Installer option is not selected
2. Everything has been mass compiled in LabVIEW 2014
Step 1 -
1. Selected Folder A which has around 70 LabVIEW controls
2. Build is successful
Step 2 -
1. Selected One single VI from Folder B
2. Build Successful
Step 3 -
1. Selected that same VI from Folder B and Selected Folder A (combining step 1 and 2)
2. Build Fail
"LabVIEW returned a linker error but did not return any missing VIs. This can mean that the missing files are RC files or other similar dependencies. Mass compile your top-level files and resolve the errors reported. If the problem persists contact National Instruments for support."
Other than "Enable SSE2 Optimization" none of the options are selected from LabVIEW VI Options.
Any idea?
Thanks,
VS

This may be useful:
http://digital.ni.com/public.nsf/allkb/19F78E0B290BFA63862574F8005A9303

TestStand Deployment Installer Media Spanning

I am creating an installer from the TestStand Deployment Utility. There is a media spanning option that permits selection of various media sizes: CD, extended CD, DVD, etc... I have created a deployment / installer (659MB) that exceeds the threshold for the standard CD (650MB). I would expect 2 volumes to be created in the deployment /installer build directory: Volume 1 and Volume 2. This is not the case, only Volume 1 is created, it exceeds the 650MB limit.
Thanks.

dpg -
Were you able to test this with a custom media size like 250 MB? Both Shawn and I were able to get the 650 MB and 250 MB media spanning scenarios working. I'd like to rule out the possibility that your deployment is so close to 650 MB cutoff that the media is not being separated into 2 volumes.
If the custom media size (250 MB) case also fails for you, then we will have a better idea of what might be causing this.
Manooch H.
National Instruments

TestStand Deployment build Internal error code 6625

I use TestStand 4.2 create a sequence which call LabVIEW code mouldes. All LabView code moudles are developed by LabVIEW 8.5.
I want to deploy it so use TestStand Deployment Utility. An error is occur when build. The log is as below:
+++++++++++++++++++++++++++++++++++++++
Starting Analysis
Processing Workspace...
Done processing workspace file
Finished Analysis
Building...
12:33
Internal error code 6625 Processing VIs...
Could not process LabVIEW VIs. Fix any broken VIs before rebuilding. LabVIEW error:
Dynamically Call Build VI Distribution LV 8.6 or Above - TestStand.vi->TestStand - Call Build VI Distribution for Unique VI Hierarchies LV 8.6 or Above.vi->TestStand - Package VIs.vi->TestStand - Build.vi->TestStand - Distribution Wizard GUI.vi->TestStand - Deployment Utility Splash Screen.vi中的Exception occured in LabVIEW: LabVIEW: File version is later than the current LabVIEW version.
An installer was not created due to an error
The build process is done.
12:33
Aborted
I already configured the TestStand adapt with LabView Run-Time engine 8.5.1. Why the TestStand Deployment Utility still Dynamically Call Build VI Distribution LV 8.6?
Could anyone have answer for this?
Thanks very much.

Gregg,
Here is a bit more information to help debugging:
This code is looking at the sequence files in the image directory TestStand - Check Linkages in SubSteps.vi get all the substeps of a user defined step type and TestStand - Check Linkages in Step.vi checks for absolute paths in the code modules of those substeps. Error code 97 means a property or invoke node got a null reference. I reviewed the code and I only see one place the error could be occurring, ultimately StepType.Getsubstep is returning a null reference for some substep.
If I can get files to reproduce the error here I can find out exactly what is causing it. Since I'm sure you don't want to post your entire system, but we can narrow it down.
First this error will only happen with a user defined step type, so I would make a test sequence that contains an instance of each user defined step type you have in your system and see if deploying the test sequence also produces the error.
If you have a large number of step types I would try to narrow it down by deleting half of the steps and saving the sequence to a new path. If the new sequence still has the error you reduced the size by half. If it doesn't the other half should have the error and you still reduced the size by half. You can keep iterating until you have a reasonable number of step that reproduces the error. At that point you could post that sequence and it's dependencies, and I will find the exact problem.
-Rick Francis

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

"BPM-70830: Deployment validation failed" when deploying from composer

Hi BPM developers,
I am trying to deploy a BPM project based on a template to Oracle BPM Suite 11.1.1.6.0 running in SOA & BPM Development VM and I get the following error :
“BPM-70830: Deployment validation failed. Cause: An unexpected error has occurred during deployment validation”
Checking the project with the Validate button returns no problem.
The weblogic log shows the following error
<Oct 30, 2012 6:13:51 AM PDT> <Error> <oracle.bpm.composer.beans.toolbar.SarExportDialogBean> <BEA-000000> <
java.lang.NullPointerException
at oracle.soa.scac.ValidateComposite.checkInterfaceInWsdlManager(ValidateComposite.java:388)
at oracle.soa.scac.ValidateComposite.validateComponentTypeReferences(ValidateComposite.java:980)
at oracle.soa.scac.ValidateComposite.validateComponentTypeServicesReferences(ValidateComposite.java:1012)
at oracle.soa.scac.ValidateComposite.doValidation0(ValidateComposite.java:502)
at oracle.soa.scac.ValidateComposite.doValidation(ValidateComposite.java:481)
at oracle.bpm.deployment.impl.ScacDeploymentService.validateProject(ScacDeploymentService.java:223)
at oracle.bpm.deployment.impl.ScacDeploymentService.generateSarFile(ScacDeploymentService.java:85)
at oracle.bpm.deployment.impl.ScacDeploymentService.deploy(ScacDeploymentService.java:150)
at oracle.bpm.pml.service.impl.ComposerMetadataServiceImpl.deployProject(ComposerMetadataServiceImpl.java:355)
at oracle.bpm.composer.service.ProjectDeploymentService.deployProject(ProjectDeploymentService.java:157)
at oracle.bpm.composer.service.ProjectDeploymentService.deploySelectedProject(ProjectDeploymentService.java:71)
at oracle.bpm.composer.beans.toolbar.SarExportDialogBean.deployProject(SarExportDialogBean.java:635)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) .....
By the way, I have been following the script from the "Getting Started with Oracle BPM Suite 11gR1" book if anyone stumbled upon the same issue.
TIA
Yiannis Tsesmelis

You're right, I restarted the server again and again...
I have just opened the sr in metalink, it has been confirmed as a bug. Unfortunately there's no way to workaround. What I can do now is waiting for the solution.

What are the advantages of using LabVIEW projects in TestStand, as apposed to just a path to a vi

What are the advantages of using LabVIEW projects in TestStand, as apposed to just a path to a vi ?
I am modifying an existing workspace for a new product, and it seems like more work to add the vi's into a LabVIEW project
does it gain anything in the long run

Hi Rusty,
I wanted to quickly clarify on the integration between TestStand and LabVIEW Projects.
As Jeff mentioned, some of the big benefits of using LabVIEW Projects is to organize code and to namespace them.
For instance if you had a project called "Power Supply" that housed all your power supply code and had a VI in that called "Initialize", and another project called "Temperature Chamber" that also had a VI called "Initialize", both these VIs are namespaced by the project, so there is no longer confusion about which "Initialize" VI is being used.
Now from a TestStand point of view, in prior version of TestStand, we lost some of this benefit because TestStand did not know about TestStand projects and called VIs simply as un-namespaced VIs. However, in TestStand 2010 (released last year, free eval available at ni.com/teststand), we added the ability to (optionally) call VIs within the context of their projects. This means that:
VIs are now namespaced by their project, even when called from TestStand
VIs can use project specific constructs like NI-DAQmx tasks and conditional compilation settings
Note: When creating deployments, the VIs maintain their projects and namespacing, so this benefit holds true for deployments as well.
Additionally, someone had mentioned looking into using lvlibs to namespace your VIs for deployment. Two comments:
With TestStand 2010, this is no longer neccessary since the project itself namespaces the VIs
You might also want to look into LabVIEW Packed Project Libraries, which combined several VIs into a single file. Think of it as a DLL specific to LabVIEW that is as easy to call as normal LabVIEW VIs. TestStand 2010 can call VIs that are exposed by PPLs. In addition, the deployment utility can automatically pack your VIs into PPLs for deployment.
Hope this is helpful!
Jervin Justin
NI TestStand Product Manager

LabVIEW VI causes TestStand Deployment to fail

Similar Messages

Maybe you are looking for