Test Mix Distribution

In Vs 2013 load test, we have an option to distribute the % for selected webtests.
For example:
Let say if we select 1000 consant users and
distribute 50% , 50% between two tests(WebTest1, WebTest2). Then is it 500 users run WT1 test and another 500 user run WT2 tests
Simarly if we specify 50% LAN and 50% 3G, Does is mean 500 users run on LAN and 500 users run on 3G ?
is this the same case with Browser distribution ?
Please share your thoughts

Hi kumaranil36,
>>distribute 50% , 50% between two tests(WebTest1, WebTest2). Then is it 500 users run WT1 test and another 500 user run WT2 tests.
The real issue would be related to how you setting your load test wizard.
http://blogs.msdn.com/b/edglas/archive/2009/10/19/using-the-virtual-user-activity-chart-to-understand-the-vs-load-engine.aspx
For example, if your two tests run 1001 times, it means there are v-users who run a test more than one times since just 1000 v-users. So it is hard for us to make sure that 500 v-users run the same tests.
Maybe you could think about use the Test Mix Based on the Number of Virtual Users Starting Tests like this case posted by you:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/8309e05d-d5bd-4dd3-8add-914bcb4c2a73/test-mix-in-load-testing-vs-2013?forum=vstest
>>Simarly if we specify 50% LAN and 50% 3G, Does is mean 500 users run on LAN and 500 users run on 3G ?
For this issue, I think it is similar to the above suggestions, it would be related to the detailed settings under the load test wizard.
This Distribution is a measure of the probability that virtual user will use a particular network type during a load test run, but the v-user would be related to the Test Mix mode settings or other settings like running settings.
For example, if you just select the "test iterations=100", it means that it just run 100 tests, so not all v-users will run the tests.
>>is this the same case with Browser distribution ?
The same as the Network Mix.
Best Regards,
Jack
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Similar Messages

Test Mix in Load Testing VS 2013

Hi Team,
I am bit confused with below options in Test Mix. Can you please tell me the difference of these options and some real time use cases on when to use which option. Thanks for your help
Based on the total number of tests:
Based on the number of virtual users
Based on user pace
Based on sequential test order

Hi kumaranil36,
This is the Official explanations about the Test Mix:
You can specify one of the following test mix model options for your load test scenario:
Based on the total number of tests: Determines which Web performance or unit test is run when a virtual user starts a test iteration. At the end of the load test, the number of times that a particular test was run matches
the assigned test distribution. Use this test mix model when you are basing the test mix on transaction percentages in an IIS log or in production data.
Based on the number of virtual users: Determines the percentage of virtual users who will run a particular Web performance or unit test. At any point in the load test, the number of users who are running a particular
test matches the assigned distribution. Use this test mix model when you are basing the test mix on the percentage of users running a particular test.
Based on user pace: Over the course of the load test, each Web performance test or unit test is run a specified number of times per users, per hour. Use this test mix model when you want virtual users to run test at
a certain pace throughout the load test.
Based on sequential order: Each virtual user runs the Web performance or unit tests in the order that the tests are defined in the scenario. The virtual user continues cycling through the tests in this order until the
load test is complete.
But I think this blog would be better for us to really understand them with the Virtual User Activity Chart here:
http://blogs.msdn.com/b/edglas/archive/2009/10/19/using-the-virtual-user-activity-chart-to-understand-the-vs-load-engine.aspx
Best Regards,
Jack
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Mixing XDCAM and HDV?? Outputting to SD DVD...

Hi
Earlier this year we shot a documentary on a Sony PDW-F350L HD XDCam (great camera, stunning footage - 35Mbps). Working in FCP has been fine.
We're doing a follow up and budget and logistics dictate that we sadly can't use 350s again (where we're going, carrying 2 Z1s for example is going to be a lot easier). We're also on a fairly steep learning curve (being relatively new to FCP, Compressor etc).
So I'm looking at options. We know that there are significant differences between say a Z1 and a 350 but from my research so far and from some relatively simple testing mixing Z1 footage (native) and 350 footage on FCP, at least editing on the timeline doesn't seem like it's going to present any problems (although thoughts on that welcome).
The issue seems to be outputting. In the first instance we'll be outputting to SD DVD. Yes, that old gem...
Searching round various forums, it seems this problem (HDV - SD) is fairly universal. Solutions seem to range from not working in Native HDV (suggestions vary on the format to ingest in - AIC etc); outputting to different formats first (eg DVCPro HD) and then to MPEG-2; outputting the timeline to tape (DV), re-importing; using some thing like a Matrox MXO to output and others...
We're aware of the shortcoming of HDV and the compressed nature of the format and our expectations, given our kit are realistic. I've even tried putting some PD150 footage on the timeline but that's just not going to cut it.
So, I've got to put a kit list together by next week and wondered if anyone had any thoughts on:
1) Mixing XDCAM and HDV on the timeline and any gotchas we should watch out for.
but more importantly
2) Any suggested routes I can look at to get some reasonable output with these two formats on the timeline - particularly HDV (don't think we'll have time to look at the Matrox route right now).
Many thanks in advance for any thoughts.
Cheers

Thanks Andy, Michael
That's good input. From an editing point of view we seem to be ok. Although, Michael, I take your point and that's a good suggestion.
The main problem is the workflow to create a decent SD DVD without the artefacts caused by compression/motion etc in HDV (and to some extent XDCAM).
Have read the prores whitepaper at
http://images.apple.com/finalcutstudio/resources/whitepapers/L342568A_ProResWP.pdf
And looked a little more into understanding GOP structures and it seems that ProRes will help in terms of editing.
The white paper seems to suggest that converting to ProRes, because it uses I frame–only encoding "Ensures consistent quality in every frame and no artifacts from complex motion. "
We'll try some tests but, does anyone know if this is true?
But it also seems that deinterlacing may solve some of the horrendous vertical edge rippling we're getting on the HDV footage when outputting to SD DVD - although if I'm honest I'm not sure how we achive that with our current setting.

HDV outputting to SD DVD... + mixing with XDCAM

Hi
Earlier this year we shot a documentary on a Sony PDW-F350L HD XDCam (great camera, stunning footage - 35Mbps). Working in FCP has been fine.
We're doing a follow up and budget and logistics dictate that we sadly can't use 350s again (where we're going, carrying 2 Z1s for example is going to be a lot easier). We're also on a fairly steep learning curve (being relatively new to FCP, Compressor etc).
So I'm looking at options. We know that there are significant differences between say a Z1 and a 350 but from my research so far and from some relatively simple testing mixing Z1 footage (native) and 350 footage on FCP, at least editing on the timeline doesn't seem like it's going to present any problems (although thoughts on that welcome).
The issue seems to be outputting. In the first instance we'll be outputting to SD DVD. Yes, that old gem...
Searching round various forums, it seems this problem (HDV - SD) is fairly universal. Solutions seem to range from not working in Native HDV (suggestions vary on the format to ingest in - AIC etc); outputting to different formats first (eg DVCPro HD) and then to MPEG-2; outputting the timeline to tape (DV), re-importing; using some thing like a Matrox MXO to output and others...
We're aware of the shortcoming of HDV and the compressed nature of the format and our expectations, given our kit are realistic. I've even tried putting some PD150 footage on the timeline but that's just not going to cut it.
So, I've got to put a kit list together by next week and wondered if anyone had any thoughts on:
1) Mixing XDCAM and HDV on the timeline and any gotchas we should watch out for.
but more importantly
2) Any suggested routes I can look at to get some reasonable output with these two formats on the timeline - particularly HDV (don't think we'll have time to look at the Matrox route right now).
Many thanks in advance for any thoughts.

Thanks Andy, Michael
That's good input. From an editing point of view we seem to be ok. Although, Michael, I take your point and that's a good suggestion.
The main problem is the workflow to create a decent SD DVD without the artefacts caused by compression/motion etc in HDV (and to some extent XDCAM).
Have read the prores whitepaper at
http://images.apple.com/finalcutstudio/resources/whitepapers/L342568A_ProResWP.pdf
And looked a little more into understanding GOP structures and it seems that ProRes will help in terms of editing.
The white paper seems to suggest that converting to ProRes, because it uses I frame–only encoding "Ensures consistent quality in every frame and no artifacts from complex motion. "
We'll try some tests but, does anyone know if this is true?
But it also seems that deinterlacing may solve some of the horrendous vertical edge rippling we're getting on the HDV footage when outputting to SD DVD - although if I'm honest I'm not sure how we achive that with our current setting.

Not getting profile in Target Info for Distribution

Hi,
I have followed all the required steps given in Program Portal. I created distribution certificates, profile and etc.
When i am trying to install this mobile profile into iphone, it doesn't take this profile.
I am not getting my profile in Target->Info. I don't know that what is problem.
One things is that when i installed certificates that time it didn't ask me any password or login. Is this problem?.
I hope that you will help me to figure this problem.
Thanks,
iPhone Dev.

have followed all the required steps given in Program Portal. I created distribution certificates, profile and etc.
When i am trying to install this mobile profile into iphone, it doesn't take this profile.
What is it you want to do, exactly? Put an app in the store or put it on a phone for testing?
Distribution is for the app store, not for install on your iPhone.

Distribution Monitor for 2 different servers from 2 different sites

Hello all,
We are trying to use Distribution Monitor during a parallel Unicode Conversion on a SAP 4.7 system.
The source system and target system are 2 different servers located on 2 different sites (more than 500Kms distant).
Questions:
1. Can we use Distribution Monitor with 1 source server dedicated for the Export and 1 target server dedicated for the import of a package?
2. If it is not possible, what are the constraints in fact?
3. Can we have a scenario where Distribution Monitor is used on the source system in order to use the parallelism benefit and Migration Monitor used on the target system?
Thanks for your help & feedback,
Chris

Hi Chris,
1. Can we use Distribution Monitor with 1 source server dedicated for the Export and 1 target server dedicated for the import of a package? The Answer is No
In order to use Distribution monitor, u need minimum two application servers on source systems and correspondingly atleast minimum two application servers on target system
For example let us say Application server A and Application server B on sources systems and Application Server C and Application server D on target ytem
Then configure Distribution monitor properties to include two application servers as source systems and two application servers as target systems. When u exeute distribution monitor preparation, first it scan database servers in source system nd target system and then scan CI servers in source and target system. Then Packages will be distributed in two application servers A and B
Run Export from Application server A for first fifty packages , at the same time Run import these first fifty packages in Application Server C
Run Export from Application Server B for other remining packages and at the same time , run import the remaining packages into Application Server D.
(that is one to one correspondence)
2. If it is not possible, what are the constraints in fact? - There is no constraints. However there is lots of time consuming during Distribution monitor preparation and checking.
3. Can we have a scenario where Distribution Monitor is used on the source system in order to use the parallelism benefit and Migration Monitor used on the target system? - The Answer is No.
You cannot mix distribution monitor tool for source system and Migration tool used on target system.
You have to use any one tool depending on the size of database used.
if your database size used is very very large then recommend to use distribution monitor where u in sou can have multiple R3load jobs in each application server. Say Application server A use 20 R3load jobs and Application server B use 15 r3load jobs).
Thanks
APR

Error when i execute a Load Test

Hello,
I have create a webtest that calls multiple WebTests (Initialize, Login, Script1, Script2) & have this added to my Load test. But when I am trying to execute my load test I get the following error:
Also, when I edit the test mix I see that the test has a RED icon next to it saying "Test "xxx" cannot be run. Please see 'Non-Runnable' test property for more details."
I have added the "IncludeDeclarativeWebTest" of all the multiple webtests that I am calling.
I am not able to understand what wrong I am doing.
Any help, appreciated!
Thanks! Vish

Hi Vish,
Thanks for your friendly response.
Could you share me a screen shot about the web tests editor? Please also share me a screen shot about all web tests in Solution explorer window.
>>one or more of the tests (directly or indirectly) included in this run could not be found.
Based on the error messages, it seems that one test couldn't be found. One idea is that you could try to create different web tests, and then check it again in load test.
For example, your web test includes 4 web tests as the dependents, you could just add one web test as the dependent, and then add two or three, check it again. At least, we could know that whether it is related to the specific one(a web
test).
Best Regards,
Jack
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Devloper app (.ipa) created to test, but I can't transfer Single edition app to updated version

Hi
I went through the process of creating the developer and distribution app. I wanted to test the distribution app before I upload to the store. You need to use a "Built-in Single Edition App" licence from Adobe to create the developer and distribution app.
Once tested we found a minor mistake. But once I rebuilt the app to create another developer file to test I found I could not use the same SIngle Edition App serial number, or transfer it, or even delete the original file and try again.
It seems a bit harsh that the process allows you to create a test file, but if you use single edition you can't change anything at that point any way.
Is there any way around this?
Regards

See http://forums.adobe.com/thread/1327845, and send a private message to Lohrii Alo. He can assist.
Neil

Does Adobe Air support mixing 14 audio tracks with different timings with no latency?

We are looking to port our iPhone application to Adobe Air and wanted to see if this is even feasible
See an app demo here: http://vimeo.com/5737825

What platforms? On Android there is or was a bug with audio latency that would interfere with your goals. The bug is in the Android OS IIRC. If you want to contact me offlist I can put together an AIR project to test mixing as many tracks as you'd like and include buttons to trigger them (source included).

ERROR -- Cannot import distribution provisioning profile

I get an Internal Error and my Xcode crashes when I try to import my distribution provisioning profile.
Here's the message:
Internal Error
Cannot remove an observer <XCRemoteIPhone 0x25ebb00> for the key path "installed" from <XCRemoteIPhoneProvisioningProfile 0x2f75180> because it is not registered as an observer.
Stack Backtrace:
The stack backtrace has been logged to the console.
======
Any suggestions?
Please help! Thank you so much for your time.. I've gotten so frustrated with this whole process.

Try using iTunes to import instead. I prefer that because XCode seems to rename the provisions to something cryptic AsdfjAOSDfasdopvAMVDO.mobileprovision whereas iTunes keeps the filename unmodified YourProfileName.mobileprovision. Then if you're browsing the directory to remove a provision you know which one you're removing instead of a confusing filename.
You can test your distribution builds by generating an Ad-Hoc profile which lets you install your distribution app on devices.

How to **dramatically** improve mix clarity!!!!

Simple answer:
M I X - O U T - O F - T H E - B O X ! ! ! ! ! !
You need:
1) an audio interface with multiple outputs (at least 8)
2) an analog mixing device: a Dangerous Music 2Bus is great, but also your dusty Mackie 16:2 will do the job. Switch off every EQs, filters and compressors on the analog board and set the faders to 0 db; you only need the summing bus of the mixer.
3) a A/D converter or a DAT machine or an audio interface with good analog inputs.
Send stereo stems of instrument submixes to 4, 8 or 16 Logic stereo outs, according to the number of audiocard outs and mixer ins.
Mono channels will be good for mono instruments: main vocal, kick drum, snare and BASS are my favorite ones to be mixed in mono.
Now you have an analog signal that needs to be re-digitalized.
The best option is to get a A/D converter, such as my Apogee Mini-Me, with USB out. I then use a laptop with Amadeus II to record the 24 bit file.
Here comes the real trick: separate the stems *ONLY AT THE END* of the mix stage, when you feel quite satisfied of the song.
After the separation, you will notice that the Logic Outs that you are using (i.e. 8 stereo outs) are no more close 0 db, but much less, because each out has less sounds summing.
Now RAISE THE MASTER VOLUME, so that the loudest output (usually the kick drum) is about -0.5 db. You will need to lower the master fader of the analog mixer about 3 or 4 db.
Now listen to the analog mix... what a difference! you will likely need to fine tune it, because the improved clarity will reveal many details that got lost in the digital mix.
Try to bounce a digital mix made within Logic (or Protools, of course) and compare it to an analog version... even if you use an old Mackie you will be blown out by the difference!

My opinion is that Cerla did give an excellent tip for dramatically improving mix clarity, only it's not exactly the tip that was intended to be given.
The key, from what I've personally experienced through my own mixes, is in Cerla's comment that "you will notice that the Logic Outs that you are using (i.e. 8 stereo outs) are no more close 0 db, but much less, because each out has less sounds summing".
A lot of people complain that the mixes they make inside the box of a DAW don't sound nearly as good as the mixes they made in an analog studio. But they're not mixing the same way. When you were recording to tape did you track everything at +6db? When you were mixing from that Studer 24trk through an SSL 6000 did you bury the master section's needles? Why is it that engineers who would never do that in an analog studio insist they must record everything into Logic/PT with all levels peaking at 0dBfs?
So here's the question: does your analog-summed test mix sound better because the analog circuitry in your Mackie 1604 sounds better than the summing algorithms in Logic, or does the Mackie win your test because you didn't push its faders up until the output LEDs refused to dip below the red?
I wonder, if you redo the test and rather than focusing on getting the best mix possible through the Mackie instead focus on making the gain staging through the Mackie the exact same as the gain staging you used on the in-the-box mix if you'll find that your analog mix has gained some of the 'typical digital harshness' that makes everyone wake up screaming in the middle of the night.
If so, and you feel like playing some more, try doing an in-the-box mix in which none of the track levels, including the master, go above -6db. Then, when your mix is as good as you can make it without breaking the -6db ceiling, push the master up to -1db with your favorite mastering plugin (or just push the fader up and let your mastering engineer finish it). It's just something to try, maybe to your ears this will be the worst thing yet. Or maybe you'll find that you can give that Mackie 1604 to the kids down the street who can put it to good use in their garage band's practice room.

Encrypted distributions

We had been testing various components of the ZENworks
policy/distribution features and had to re-run some of them do to patch
releases, etc.
Originally, we tested encrypted distributions and were successful.
Currently, when I attempt to create a distribution, on the General tab of
the distribution the Encryption option is greyed out (inaccessible to
choose) and a comment states that "no encryption support is available on
the Distributor."
I couldn't find anything on the KB or documentation...has anyone
encountered this issue?
Thank you,
Dave

> On the distributor, when you start zfs, Do you see "unable to generate
> Ephemeral keys".
>
> Did you distribute the certificates between the distributor and
subscriber?
>
Jared,
Yes, the certs had been distributed (the encryption had been working),
but in the zfs-start.log file there is now an error with Ephemeral keys.
I had a reply from our Novell support late on Friday indicating that a
file mismatch may be the culprit...in fixing one problem, the encryption
was broken (or, at least that is the only thing that changed since it was
working) and now we are to apply a full HP2 codeset (we had only been
given a component of the patch to fix the original issue).
I will follow up if the patch resolves the issue. If there is anything
else I can check, please let me know.
Thanks,
Dave

Plisp: Lisp/S-expression parser library

Plisp is a C library for parsing Lisp/S-expressions. I wrote it because I got massively sick of writing the same code every time I wanted to parse a text file.
I'd like some testers/users for this. It suits *my* needs, but I'm not too good at accommodating other people's. Do give it a try.
Installation:
I decided to mix it up and use Mercurial instead of Git. I'm liking the change.
AUR package is here: http://aur.archlinux.org/packages.php?ID=35422
hg clone URI (also web view): http://peasantoid.org:1024/plisp
Manual installation:
$ root=/path/to/root_directory ./make install
Documentation:
Sorely lacking. I will attempt to write some of this later; in the meantime, look at the source (particularly header files) and everything in test/.
Technical details:
Text is processed in two stages. The first, tokenization, iterates through the text looking for 'simple' tokens (left/right parentheses, quotes, numbers, strings, symbols, etc.). The second, parsing, iterates through the token list and converts it to a parse tree.
POSIX ERE (extended regular expressions) are used for tokenization. Seriously, this is really handy. $(man 3 regex) for details.
Linked lists are heavily relied upon.
Note that numbers are just stored as strings. It's up to the programmer to change those to actual numbers (f.e. strtol(), strtod()).
Testing:
The distribution includes a simple syntax-dumper utility that takes data from stdin, parses it, and formats the resulting syntax tree to stdout. My terminal transcript follows:
narch plisp -> ./make test && build/test/dump
---[RUN test (lib)]
---[RUN lib (obj)]
---[RUN obj ()]
build/obj/error.o
build/obj/escape.o
build/obj/init.o
build/obj/list.o
build/obj/parser.o
build/obj/tokenizer.o
---[END obj]
build/libplisp.so
build/libplisp.a
build/include/*.h
---[END lib]
build/test/dump
---[END test]
(foo '("bar") `(3.456 ,(baz 4 5)))
^D
1:1 list: ...
1:2 symbol: foo
1:7 list (quoting: '): ...
1:8 string: bar
1:16 list (quoting: `): ...
1:17 real: 3.456
1:20 list (quoting: ,): ...
1:21 symbol: baz
1:25 integer: 4
1:27 integer: 5
Tested by/on:
me: Arch 64-bit (x86_64 Intel Core 2 Duo (Apple MacBook3,1))
me: Arch 64-bit (x86_64 Intel Xeon (Xen))
me: ArchPPC (32-bit PowerPC processor (Apple Mac Mini G4))
If you test this, please post your architecture and processor type. I really hate those insidious system-specific bugs.
Last edited by Peasantoid (2010-03-13 05:31:46)

Peasantoid wrote:Interesting thing I discovered: you have to pass '-lm' to GCC in order to get it to link with the math functions. Does anyone know why this isn't in libc?
I've encountered this before, it's one of those things that make you go "huh?". Nice work on getting the math module done
As a suggestion, it would be useful to have a module which allows loading and running arbitrary functions from shared libraries, although I'm not too sure where to start with implementing this, I think there is a library around that allows you to do this fairly easily, but I can't seem to find it right now. But as a relatively new scripting language something like this would make it easier to interact to common libraries while other modules are still being written.
Edit: Obviously I was searching for the wrong thing, what I'm talking about is a foreign function interface
Last edited by HashBox (2009-06-13 01:43:44)

Why autocreate function confuse different PRs in one PO?

I created PO using autocreate function from different PRs. It was not possible to select "requisition" grouping, only "default". The result is a totally confused PO with mixed distributions, prices, etc. The total amount is also different from the PRs summarized amounts.
Should I forget autocreate in this case or is there any solution for this problem?
Thanks in advance.

Dear Szabolcs,
I am explaining you after doing on my test instance 11i (11.5.10.2).
(1) If we are going for Autocreate with Grouping = Default , it will consolidate the PR line.
(2) If we are going for Autocreate with Grouping = Requisition , it will create a separate PO line even though there is a same item and
same Need-By date on PR level. Also price will remain intact as per PR line.
In both the case, please set the following profiles to NULL value.
(1) PO: Default Requisition Grouping
(2) PO: Use Need-by Date for Default Autocreate Grouping
HTH...
Sanjay

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

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

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

Test Mix Distribution

Similar Messages

Maybe you are looking for