TestStand Equivalent to VB's CreateObject

Is there a way to create an ActiveX object using TestStand without having to point to a type library?
For example, in VB, VBA, and VBScript, you can create an object using the following syntax:
set obj = CreateObject("Library.ClassName")
Is there a way to do this in TestStand? I have a COM Server that I'm trying to use that doesn't have a TLB associated with it, therefore it doesn't show up in the list of Automation Servers in the ActiveX Adapter dialog box.
I can access it via VB however.
Thanks in advance for any help.

Jeff -
The Automation Adapter does not allow you to specify a server, class, or parameters without the type library. My only suggestion is to use a wrapper server in VB to assist you in working with this server that does not have a type library.
Scott Richardson
Scott Richardson
National Instruments

Similar Messages

Hex display in LabVIEW TestStand equivalent

Hi, I am trying to communicate to a device using RS232 communications.
The command i need to send in hex is 5054 4958 2001 200A 0D
This cannot be represented by ASCII characters, i.e. it appears as PTIX .
I can achieve this no problem in LabVIEW by setting the string control to 'Hex Display' but when I try to load the hex string via TestStand it becomes 3530 3534 3439 3538 3230 3031 3230 3041 3044 which is the hex display of 5054 4958 2001 200A 0D.
Is there anyway that I can export the hex command into the LABVIEW VI? I tried important the decimal number equivalent and then using convert number to hexadcimal string but this doesn't work as the hexadeciaml string is
505449582001200A0D
but the actual string should be PTIX
I have attached my code and any suggestion would be welcome.
Rgds,
Sean
Attachments:
Sean RS232 Commv2.vi ‏33 KB

Not sure why you would try Number to Hex String. What I've done in the past is use a numeric array and the Byte Array to String or a numeric and the Typecast function. Both of these functions have been discussed endlessly in posts about sending hex with a VISA Write.

Equivalent to Step.Limits.Low.NumericFormat in TestStand 3.1?

I am looking to set the Limit Numeric Format property (for individual steps) programmatically through the TestStand API. The link below seems to be talking about the property I need to set (Step.Limits.Low.NumericFormat).
http://forums.ni.com/t5/NI-TestStand/How-can-I-tell-that-a-default-numeric-format-has-been-applied-t...
Unfortunately on my TestStand 3.1 system, the property doesn't exist (or doesn't work as Raj suggests in the post). Everything is fine on my TS 4.2.1 system.
Does anyone know the name/location of the property in TS 3.1. It must exist as it is possible to modify the display format of limits in TS 3.1. I guess it may not be possible to interact with it through the API which would be a shame.
Regards
Steve
https://decibel.ni.com/content/blogs/DailyCLAD
Solved!
Go to Solution.

Hi Shalini
Thanks for your post. It was helpful but I am not quite there.
If I export a single NumericLimitTest step Step.Limits into LimitLoader format, I get the following:
<Step Name> Limits
Numeric Limit Test <Prop Name='Limits' Type='Obj'><Prop Name='Low' Type='Number' NumFmt='%#x'><Value>9</Value></Prop><Prop Name='High' Type='Number' NumFmt='%#x'><Value>11</Value></Prop><Prop Name='LowExpr' Type='String' TypeName='Expression'><Value></Value></Prop><Prop Name='HighExpr' Type='String' TypeName='Expression'><Value></Value></Prop><Prop Name='UseLowExpr' Type='Boolean'><Value>False</Value></Prop><Prop Name='UseHighExpr' Type='Boolean'><Value>False</Value></Prop></Prop>
<Locals> Variable Value
<FileGlobals> Variable Value
<StationGlobals> Variable Value
So it is the value of 'NumFmt' that I need to set, and the value I need to set it to is '%#x'.......but I am not sure what 'NumFmt' is; it is not a property, it is associated with Limits.Low (and Limits.High), but it isn't a sub property of Limits.Low as Limits.Low is defined as a Number.
I can successfully import the NumFmt of Limits.Low (using the LimitLoader) in TS 3.1, but I am missing one last clue defining how it is done in the API
Regards
Steve.
https://decibel.ni.com/content/blogs/DailyCLAD

Deciding whether TestStand is the right solution for my company

I'm working at a growing company and we recently started a push in our Test group to try and standardize our future development as much as possible to allow as much re-use of code as possible. I don't want to say exactly what it is we make for confidentiality reasons, but let's just say that 90% of what we make is the same basic type of product, but it comes in literally hundreds of models ranging in size from about the size of a dime to the size of a small washing machine. We're considering switching to TestStand on all new stations and on all updates of previous stations to assist in rapid development with increased efficiency.
Over the years we've made about 20 or so test stations as new versions of our product came out, each able to fit products of a different size and with different test requirements, but because our main products are all so similar to each other, there's only a pool of about 6 different types of tests we need to run, with some products needing only one of those tests and others needing all 6, and plenty in the 2-5 range. The size differences among different products also mean we have a large amount of different power supplies, and for various other reasons the measurement devices for the test stations aren't terribly standardized as well.
Step 1 was that we standardized the database we used to store all of the test data. We now have one database that can store data from all of our test stations in the same way. A few of the old stations had to have some creative workarounds done (i.e. instead of rewriting their current test program, write something that takes their old output format and converts it to the new database format, then upload it), but this step is 100% complete.
Step 2 was to abstract out the most common pieces of hardware, so we have started basically putting the IVI types in a LVOOP wrapper. Now instead of being limited to interchangability among IVI devices we can also swap in any of the other assorted devices we've accumulated over the years, many of which don't have IVI drivers and even a few that don't follow SCPI standards, as this is a great use of inheritance and overrides. We're also implementing a few device types that don't have IVI classes. This effort is already well underway and we're OK here.
Step 3 is where we're at now. As we standardized on hardware interfacing, we also figured it would be a good idea to attempt to effectively write each of the 6 or so tests one last time each with very flexible setup parameters as inputs, using the abstracted hardware classes so that it wouldn't matter which hardware we had, so that all the tests would run the same way. So we started looking at solutions to some form of sequence management, and we came up with a couple of possibilities for homegrown versions but after debating those for a while we started to ask ourselves, "Are we just re-inventing TestStand here?"
We use TestStand on a few stations here already so we had licences for development, but the stations we use it on at the moment fall into the 10% of outliers that we have and are somewhat non-standard. So none of the 6-ish usual tests were used on them and they're for a very different product type, so we never tried to use them with our standardized database. They also were all made before I came on board here, so I don't have much experience with TestStand myself, and I've run into some roadblocks when trying to come up with a framework for how to integrate our standard database and our standard instrument LVOOP classes into a TestStand environment that meets our current and future test requirements.
The first roadblock is that our database standardization and TestStand's built-in reporting don't mesh at all. Right now, all of our test stations use the same "mega-cluster" to store their data in, which is a type-def cluster of all the things our products could ever be tested for on any of our stations. We pass it to a common database write function that writes everything that has changed from the default values (NaN and blank strings\arrays) and ignores the rest, so we don't fill the database with zeroes for the tests we don't do. I do want to emphasize how big this cluster got in order to have all of the potential save values we might ever need in it. It is a cluster of 13 other clusters, the largest of which has 10 items in it, and one of those is a 1-D array of another cluster with 19 elements in it, and one of those elements is another 1-d array with a cluster of 24 units in it. If all of the controls in the mega-cluster are shown on the front panel at once, I can't fit them on 2 full-size 1080p screens at the same time. The context help for the main cluster is 5 screen heights tall just for the listing of all of the elements.
So I really can't see this being integrated with the built-in TestStand reporting system. Additionally, the "Type" system in TestStand appears to be unhelpful when attempting to pass this cluster between steps, and even worse when trying to pass it between sequences. When I add the mega-cluster to it, it also creates over 30 other types, one for each of the other clusters contained inside of it. Within LabVIEW alone this is pretty easy to manage, as we just have a centralized repository of typedefs in source control that gets checked out to a common directory on each computer, as we do minor changes to acommodate new products a few times a year. However, on TestStand, I can't find a method that's the equivalent for just storing a bunch of .ctl files in the same shared directory like we do with LabVIEW. I see that they can be stored in certain INI files or in sequence files. The INI files appear to all be station-specific, and since all of our 20ish test stations have different hardware and capabilities, we can't just synchronize those files. And if I want to pass the mega-cluster type between sequence files that call sub-sequence files, every one of those files will need to be manually updated to get their types to match... and we'lll be needing at least 200 sequence files when we're done, at a guess. Unless there's some method I'm missing here, I don't see how to use TestStand to move this data around. We could use something like just passing it by reference, but then if we do that I don't actually see much of a benefit here of using TestStand instead of just pure LabVIEW as two of the things that TestStand is supposed to handle (reporting steps as pass/fail against limits and reporting and logging the results afterwards). Plus then we have the additional burder of making sure the module holding the reference in LabVIEW doesn't unload before we're done using it.
Is there some better way of handling massively complex types in TestStand that I am not seeing?
There may be more that I'm not seeing yet, but if there isn't a way to handle these massively complex types in TestStand, all we'd be getting out of it is a slightly easier method of managing sequencing than we have now, which I don't see as being worth the investment in time and licenses it would take.
I'd be grateful for any feedback. Thanks!

Considering you already seem to be leveraging LabVIEW heavily and before jumping into TestStand I would look at the PTP Sequencer. This seems to be a cutdown version of TesStand but inside LabVIEW and is a simple install from the LabVIEW Tools network using VIPM.
If you are happy to look at alternative representations then maybe check out NI's StateChart Module or the Open StateChart by Vogel (available as an install from VIPM).
The advantages of any of the above is they will be alot cheaper than TestStand and the required run time licences if you don't require all the power of TestStand (extensible everything).

ASCII equivalent of CF's URLDecode?

Hello, everyone.
Even though I've been working with CF for over a decade, this is going to sound like a total n00b question. I'm just drawing a blank, right now. Google isn't much help.
Is there an ASCII equivalent of URLDecode??
Where I work, everything that is inserted into a database goes through a filter that changes certain characters to their ASCII equivalent (ie, the less than "<" is altered to "<"). For displaying the data, I need to revert the < back to < for formatting (there are <br /> in place of line breaks, in the data.)
If not, I suppose I should check cflib to see if there is a UDF. Hmm..
Respectfully,
^_^

Well, first, that's not ASCII encoding, that's HTML Entity Encoding.
Second, no. There is not a built-in function for decoding HTML entities. The purpose of the function is to use it when displaying output to the screen, not to use it before sotring data for later use.
Obviously that doesn't help since you already have a system that encodes before putting data into the DB. So you need a way to decode it.
If you are using CF8 or CF9, with all of the security hotfixes installed, or you are using CF10, then you'll have ESAPI available to you via Java integration. ESAPI is a security tool from OWASP with built-in encoders and decoders. You can use those. Here is how.
<cfoutput>
          <cfset string = "<hi>" />
          <cfset list = createObject("java", "java.util.ArrayList") />
          <cfset htmlCodec = createObject("java", "org.owasp.esapi.codecs.HTMLEntityCodec") />
          <cfset list.add(htmlCodec) />
          <cfset encoder = createObject("java", "org.owasp.esapi.reference.DefaultEncoder").init(list) />
          #string#
          <br />
          #encoder.decodeForHTML(string)#
</cfoutput>
Hope that helps.

How to use Unicode characters with TestStand?

I'm trying to implement the use of Greek characters such as mu and omega for units. I enabled multi-byte support in the station options and attempted to paste some characters in. I was able to paste the mu character (μ) and import it from Excel with PropertyLoader. However, I have not had any luck with omega (Ω). I found the HTML codes for these characters on a web page (http://www.hclrss.demon.co.uk/unicode/) so I could use those codes for HTML reports, but that won't work for database logging, nor does it display the characters correctly for the operator interface. The operator interface is not a major problem, but the database must have the correct characters for customer reports. Anyone know how to do this? D
oes database logging support Unicode for stored procedure calls to Oracle?

Hello Mark -
At this time TestStand has no unicode support. The multi-byte support that we do offer is based on the Windows architecture that handles Asian language fonts. It really isn't meant to provide a bridge for unicode values in TestStand. Certainly, your Operator Interface environment will have its own support level for unicode, i.e. at this time neither LabWindows/CVI version 6.0 nor LabVIEW 6.1 officially support unicode characters. This is why you will see that the units defined in the TestStand enumerators are all text-based values.
I have run a quick test here, probably similar to what you were doing on your end, and I am uncertain if you will get the database behavior you want from TestStand. The database logging steps and API all use basic char sty
le strings to communicate to the driver. Even though you are reading in a good value from Excel, TestStand is interpreting the character as the nearest ASCII equivalent, i.e. "Ω" will be stored and sent to the database as "O". If you have a stored proceedure in Oracle that is calling on some TestStand variable or property string as an input, then it is doubtful you will get correct transmission of the values to the database. If your stored proceedure could call into a spreadsheet directly, you would probably have better luck.
Regards,
Elaine R.
National Instruments
http://www.ni.com/ask

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.

Calling WPF from TestStand

Hello,
I was wondering if it is possible to develop WPF GUI's that can be called by TestStand. Ultimately, I would like to create a WPF DLL which can be called by TestStand and fed parameters back and forth.
At the moment I'm trying to just do a very simple WPF form (no parameters, just a message in a window), however, I am having trouble doing this. I am able to create the DLL in Visual Studio 2010 but when I try to call it in TestStand, it does not seem to work. I'm also not sure if I am using the correct Action Adapter. I tried calling it as a .NET adapter but when I do I get the following error:
An exception occurred inside of the call to .NET member 'UserControl1':
System.InvalidOperationException: The calling thread must be STA, because many UI components require this.
   at System.Windows.Input.InputManager..ctor()
   at System.Windows.Input.InputManager.GetCurrentInputManagerImpl()
   at System.Windows.Input.KeyboardNavigation..ctor()
   at System.Windows.FrameworkElement.FrameworkServices..ctor()
   at System.Windows.FrameworkElement.EnsureFrameworkServices()
   at System.Windows.FrameworkElement..ctor()
   at System.Windows.Controls.Control..ctor()
   at WpfControlLibrary1.UserControl1..ctor() in c:\users\mcooblal\documents\visual studio 2010\Projects\WpfControlLibrary1\WpfControlLibrary1\UserControl1.xaml.cs:line 22
I can attach files if that helps, just let me know. In the meantime, I'm going to keep looking for solutions.
Thanks!
Mukesh.

The error says, "The calling thread must be STA, because many UI components require this".
STA is a COM/ActiveX threading model. By default, TestStand threads use MTA rather than STA. Using a sequence call step with its execution option set to "new thread" you can call a sequence using an STA (Single Threaded-Apartment) thread by checking the option for it on the advanced panel of the module settings. You will then likely want a "wait" step immediately after the sequence call to wait for the thread to complete before continuing.
Another alternative is to do the equivalent in your .NET code module (i.e. create a new STA thread internally in your .NET code and have that run your dialog, while the original thread waits for it to complete).
Hope this helps,
-Doug

Returning a Tcl list to TestStand

Hi,
I wonder if anyone can help me. I would like to return the contents of a Tcl list to TestStand. I am not sure how to go about it. Are Tcl lists equivalent to an array in TestStand? Can I return the entire list or must I return each individual element? I also noticed that the custom TclParameter type can be modified. Should I create an array of strings to catch the list being returned from Tcl.
Any help would be appreciated.
Thanks

A Tcl list is very similar to an array in TestStand. There are some minor differences when dealing with multi-dimensional lists (lists of lists), but the concept is pretty similar. The Tcl Example currently on the web does not support lists and all parameters must be strings. You would then have to parse the string returned as the list in order to make an array.
For example, if you have a Tcl list x created with": set x [1 2 3 4]". If you set an output parameter on the step to map to the variable x to Locals.ListAsString in TestStand, it would be populated with "1 2 3 4". You would have to then split the string based on spaces, and you could convert it into an Array in TestStand.
Do not modify the TclParameter type (unless you also want to change the source code of the rest of the step). Changing the source code for the step type would be an advanced topic, so unless you are experienced in TestStand and the Tcl C API, I wouldn't recommend it.
Allen P.
NI

Adding a Entrypoint String in NI_ParallelModel Data (Teststand 4.2)

Hi,
I am converting a 2012 Parallel model sequence into a Teststand 4.2 Parallel Model.
First issue I saw is the insert field in the Parameters('Pre UUT').Modeldata, is greyed out. Basically I would like to add the string "EntryPoint".
The Parameters('Pre UUT').Modeldata is passed by reference, type is NI_ParallelModelData which is similar to 2012 parallel model.
Any ideas?
Thanks!
Don

Hi Daniel,
I am downgrading existing 2012 Test exec with custom interface to 2009 equivalent version.
The custom interface in 2012 needs the Entrypoint field in the parameters.modeldata (type NI_ParallelModelData2)
In 2012, the custom interface is called at DoPreUUT, but in 2009, it does not use DoPreUUT, but I can give a try to mimic it.
Then in the parameters.modeldata it does not have entrypoint field.
Where is the menu for the migrating from 2012 process model to 2009 process model?
Thanks!

LabView/TestStand Developer - Herndon, VA

Senior Production Test Engineer
Job Description:
ABOUT THE COMPANY iDirect is dedicated to providing next generation solutions for broadband IP networking via satellite networks. For more than 20 years, the VT iDirect organization has focused on meeting the economic and technology challenges across the satellite industry. Today, the product portfolio, branded under the name iDirect, sets new standards in performance and efficiency, making it possible to deliver voice, video and data connectivity anywhere in the world. As the leading innovators in the satellite communications industry, our diverse and talented team of Internet, satellite and telecommunications professionals continues to break new ground and create significant opportunities for network operators, for service providers and resellers, and for corporate networking professionals. If you are ready for the challenges, responsibilities, and rewards that come with working in a high-energy, fast-paced environment, then this is the job for you!
ABOUT THE POSITION
We are looking for a true leader in the area of production test development and implementation to significantly upgrade our capabilities and sophistication in an outsourced manufacturing environment. This is a unique opportunity to develop, implement and lead the vision for production test engineering. The Senior Production Test Engineer will be in integral part of the global manufacturing operations team and will interact with the Software and Design test functions. This is a great opportunity to join a growing company in a rapidly developing industry.
RESPONSIBILITIES:
Participate in all aspects of product testing within the manufacturing environment.
Develop, debug and maintain LabView/TestStand code to support production test.
Partner with Manufacturing Engineering, Quality and Reliability teams to monitor, measure and improve production yields. Develop and optimize the debugging approach incorporating a closed loop corrective action process for root cause identification and correction.
Identify test process cost savings opportunities and work with other Supply Chain teams to identify and realize regular efficiency improvements and cost reductions.
Lead projects to improve existing test systems and solve any issues that prevent delivery of professional testing capabilities.
REQUIRED EXPERIENCE:
The ideal candidate will come from a communications electronics environment with emphasis in wireless communication, and have a thorough understanding of current test strategies and approaches. In addition, the candidate should have the ability to develop and articulate a clear vision for effective and cost efficient production testing in outsourced manufacturing.
BS in Engineering required. BSEE preferred, BSEET, computer science/engineering or equivalent experience will be considered.
10+ years in test engineering or related areas in complex electronics manufacturing environment.
5+ years of experience working at or with a Contract Manufacturer.
Experience with LabView/TestStand, Boundary Scan, BIST, POST.
Strong technical documentation skills including test requirements and test plan development.
Solid understanding of software design and debug.
DESIRED EXPERIENCE:
Experience using databases such as SQL.
Experience with a variety of programmable instruments; such as Spectrum Analyzers, power dividers, signal generators, logic analyzers, etc.
Significant RF experience and wireless communications strongly preferred.
Knowledge of application of test methods (ICT, AOI, and RF communications) desirable.
Experience with National Instruments hardware a plus.
Experience programming and interfacing ATE's in VB, C, C++, LabView, shell scripts, Perl, programming language skills for measurement, data acquisition and instrumentation control a plus.
Equal Opportunity Employer M/F/D/V

Hi,
Kindly arrange an interview process.
I have attached my resume
Regards,
Bharath Kumar

Assessing Command 'Analyze Source Files' via Command Line when running TestSTand Deployment Utility

Our Software Configuration Manager is running the TestStand Command Line Deployment Build Tool (Ref: https://decibel.ni.com/content/docs/DOC-38947).
        When he builds the application, the code will not be at the same location it was in development.
If you are Manually running the TestStand Deployment Utility, This is not a problem because everything is relative in the workspace.   Simply go to the Distributed Files Tab (of TestSTand Deployment Utility) and hit the, "Analyze Source Files" button. This finds the required files and apparently creates an updated hard path to be used during the build (probably in the *.tsd).
PROBLEM: We auto-run the Command Line Deployment Build Tool (Command Line), and we do not have access to the, 'Analyze Source Files' command.
            As a result, our build consist of many warnings and the output is missing many files (the location of the files have not been updated).
If we could access the 'Analyze Source Files' Command via command line, that would fix the issue.
FYI: We use an automatic builder called Quick Build as our builder.
Attachments:
TestSTand Deployment Utility-Distributed Files Tab.PNG ‏76 KB

Unfortunately it looks like Analyze Source Files does not have a command equivalent for the command line based on this article and attached PDF:
https://decibel.ni.com/content/docs/DOC-38947
That may be a good post for the TestStand Idea Exchange for consideration in future versions of TestStand.
Michael K.

Recovering from ActiveX Error in TestStand

If I were running a CVI DLL code module from TestStand using the CVI
adapter and terminated it somewhere in the code module by using the Windows
SDK ExitProcess(0); command it will return to TestStand and generate an
ActiveX error as follows:
" -17702; An error occurred accessing the CVI ActiveX
automation server.The CVI adapter will attempt to reconnect on next
execution."
It appears any subsequent communication to the CVI server in this same
execution (i.e. by other steps that follow) will fail also until the
execution is re-started. Is there a way to reset/restart the communication
in this sequence's execution between TestStand steps? i.e can the CVI
adapter reconnect on this execution. How does TestStand re-establ
ish
communication with the CVI server using the CVI adapter ? Does it have to
destroy that object and create a new one to recover ?

Scott,
Your recap is excellent. The SDK ExitProcess() function is called in a different thread in our code module when the Terminate button on our ActiveX operator interface is clicked. This kill's the code module immediately and returns to TestStand with an ActiveX error which can be ignored. Then the Cleanup group can be run to reset the test equipment. At this point you must restart another execution to reset the ActiveX connection. This model works well if you are resetting and not trying to perform other steps once you return to TestStand. This implies our code module will always be run out of process. I tried the Time Limits idea you suggested but that still does not terminate the thread our code module is executing in. The RaiseException idea I also tried. I raised the exception in the main thread of the code module that was executing. This has the side effect of returning to the CVI debugger instead of TestStand which is not good. We are going to stick with the ExitProcess() method for the time being and see how it works in the long run. In the next version of TestStand it would be nice if this feature could be added. Also for your info due to TestStand's architecture it seems all code module's that are called using the CVI adapter must return from the main of the code module that was called in TestStand. This implies that if the main has several layer's of functions below it that it calls. Somehow these call's must recognize (poll) for the termination event from TestStand and return all the way up the call stack back to the original code module that was called by TestStand. Therefore all of the users code/function's must error check every line of code in the main to see if we want to return and every function must check every line of code to return up the stack to the main. This makes the code a lot less readable in main for example if(function == FAIL) return -1; instead of function();. The only alternative to this method that I have found is the ANSI "C" setjmp/longjmp command which will allow us at any point in our Test Code or sub function's to return cleanly back to TestStand. This is preferable to me because the code is more readable and functionally equivalent to returning up the call stack. Do you know of any other methods of doing this ? Our individual code modules may be up to 1000 lines and take anywhere from 1 - 10 minutes to complete with many nested function's being called from the main.
Thanks For Your Help,
Tom D

Passing information between parallel Teststand sequences.

The ExecutingCodeModulesInParallel example that came with Teststand 3.0 almost does exactly what I want. The example uses steps that run CVI. I am trying to create a LabVIEW equivalent of this example. Basically, I want a LabVIEW Display panel 1 to write to FileGlobals.Counter1 and a LabVIEW Display panel 2 to read from it during parallel execution.
Right now, I can’t seem to get the information to pass between the two displays.
Once I figure out how do this, I believe I will be able to apply it my specific task.
I’m a newbie when it comes to Teststand and LabVIEW. Any help would be greatly appreciated

Hi,
The problems is your VI loops dont actual set the FileGlobals.Finish1 boolean and Counter1 until the stop buttons are press by which time you probably have missed them and like wise your other VI only reads the TestStand variables when the VI is launched.
You need to call the PropertyObject.SetValBoolean method either by using the appropiate VI from the Teststand palette or via the Invoke node. In the other VI you will have to call the PropertyObject.GetValBoolean method and GetValNumber method. This also means you will need to pass the SequenceContext to both VI's.
Have a look at the original example again and you will spot the relavant calls in the two C functions.
I will post you your modified VIs later today.
Hope this helps
Regards
Ray Farmer
Regards
Ray Farmer

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

TestStand Equivalent to VB's CreateObject

Similar Messages

Maybe you are looking for