NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

type file managment with source code control

Hi,

 

I've recently been enlightened by a consultant of the importance of source code control and the payoff you get in efficiency and code reuse with proper SCM.  (Yes this is a shout out to you Golden Tech Systems).

 

So now I wish to configure the components of TestStand to go into SCC.  I'm using Perforce and I've created a client workspace for my TestStand Components.  I'm not talking about sequence files or code modules.  I've manage to figure out how to point my users.ini file to this location but i think it makes sense to do this with all the important coponents such as my process models, stationglobals and all the other stuff that makes TestStand so awesome.  Has anybody had experience with this?

 

So now for the real purpose of this post.  TestStand seems to have this built in system for type management and it's not obvious to me on how to use proper SCC for managing types.  The goal is for me to have all my test engineers using TestStand and using the same types.ini file when they are developing and also to make sure the same file is deployed out to testers.  Any suggestions are greatly appreciated

0 Kudos
Message 1 of 24
(2,573 Views)

Rule #1 with type files:  NEVER DEPLOY THEM  TO DEPLOYMENT MACHINES!!!!

 

Why?  Because the types are automatically copied over to your sequence files when you instantiate them.  Therefore you are just deploying unnecessary files. 

 

Now to answer your multi developer environment question:

 

Basically you need to duplicate the TestStand public folder in your SCC and then have all your developers point to it as their new TestStand public folder.  This document will give you insight into how to change TestStand to point to a new public folder: http://digital.ni.com/public.nsf/allkb/42A0D8B0DCEC64FE8625744F007F3A6D

 

In the public folder you can put your type files.  Put them in the Components\Type Palettes folder.  Another great advantage is that you can share process models, reporting mechanisms and front end callbacks.

 

Hope this helps,

jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 2 of 24
(2,543 Views)

Perhaps there is some reason why jiggawax is recommending to not deploy type palette files that I am unaware of, if so, please elaborate.

 

But in general, I'd recommend exactly the opposite (i.e. always deploy a type palette file). The the reason being, without a type palette file, what version of a type you get at runtime will be somewhat non-deterministic unless you meticulously ensure all of your sequence files are saved with the same version of the type. The reason is that whichever version of the type you have in whichever sequence files you load will be the one you get, even though it might not be the latest or the version of the type you want. Also you could end up with type conflict errors at runtime in the middle of a long run if sequence files are loaded dynamically. Also such runtime errors might only occur in certain cases depending on the order in which the files are loaded, which makes debugging such problems more difficult and the behavior more unreliable.

 

Using a type palette ensures you get the version of the type in the type palette and don't end up accidentally using some older or newer version, no matter what version of the type your sequence files were last saved with. By default, if a type is in a loaded type palette file, you either get that version of the type, or a type conflict error. One downside though is that it's harder to dynamically change which version of the type you are using. Though it is possible since you can programmatically load and unload type palette files.

 

-Doug

Message 3 of 24
(2,537 Views)

There are several problems with deploying type files.  Here are a few:

 

  1. It is unnecessary.  You already have the type defined in your sequence file.
  2. It can cause run time errors.  If the type is created for a specific module and you change the type and the module doesn't update then you can get run time errors.  Because the prototype has changed.
  3. It is an extra layer of maintenance.  Now you have to maintain on the dev environment and the development environment and spend time re-deploying those files.
  4. A lot of times development is done on deployment machines (because of instrument constraints).  If you are just trying to make a quick change in legacy code but your environment is trying to load a newer type you now have to account for all those instances.  What was a 10 minute update could quickly turn into a 3 day project.

In my experience I have found it is best not to deploy them because issues are reduced dramatically.

 

Anyhow, take it for what it's worth but that's my 2 cents.

 

Regards,

jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~
Message 4 of 24
(2,523 Views)

Hi ~jiggawax~

 

Thank you for the link and this looks like it's exactly what I need but after I add this value to my registry teststand is still pointing to the default location.  I'm using TS 2010 SP1, could this be why?  Is there something else I'm missing?

0 Kudos
Message 5 of 24
(2,504 Views)

Hi Chilidog

Sorry for highjacking but would like to place some comments on upper messages. 

 

I know that NI recommends to use the type files. The way NI arguments is absolutely right.
But i have to agree Jigg!


My expericence told me the same.
When starting with types i did it in recommend way. And as Jigg mentioned a lot of stuff was done on the maschines itself.

During development the Step- and Datatypes and has been updated caused bugfixing and new feature requests.

The result was type conflicts, runtime errors and even the creation of type viruses on the productions maschines.

http://forums.ni.com/t5/NI-TestStand/type-conflict-error-when-using-TS-EngineGetSeqFile/m-p/622686/h...

 

When i had realisized that it is unnecssary, because it is in the sequnece file, too
The Conflicts on the production maschines were gone. In my case most SequenceFiles with its step- and datatypes are only valid for
special maschines and tests. It makes no sense to excute them on other maschines, because instruments are not present.

 

To be honest, on development maschines the conflicts were still present. They only occure when opening SequenceFiles with different types.

 But you are able to manage them better without filetypes.

In our development we have just one simple rule: "When ever a conflict occours and you do not know why, just close TestStand WITHOUT saving.

Reopen TestStand with the SequenceFile you work with." In most case this will solve the conflict.

 

So Jigg lets hope, that NI supports type stuff in sequnence files in every future release.

 

Regards

 

Juergen

--Signature--
NIWeek 2017: Standardized HIL Test Automation With TestStand
NIWeek 2016: Capturing ATE Requirements With Requirements Gateway

Feedback or kudos are welcome
Message 6 of 24
(2,498 Views)

Hi Juergen,

 

thanks for the input, I will avoid deploying typefiles to my production machine.  Now I'm going to hijack this back

 

Anybody have success using the following link to configure the TestStand public directory location?  I tried it but my machine still looks like it's pointing to the default location

 

 

 

 

TestStand public.PNG

0 Kudos
Message 7 of 24
(2,492 Views)

I agree that there is likely a usability issue that needs to be addressed, so I would like to better undersand why people aren't using type palette files, but there are some misconceptions going on which I will try to clear up.

 

1) Only one version of a type can be used at a time. If you don't use type palette files and you load 3 files all with different versions of a type, they will all use the version of the type with the highest verison number regardless of the version of the type they were saved with.

 

2) Using type palettes in recent versions of TestStand is the way to avoid type virus-like propagation. The type conflicts only occur where virus-like behavior would have occurred without them. The conflicts are there to protect you from the unintended type propagation. In older versions of TestStand that was not the case, rather than have conflicts, type propagation occurred silently. In newer versions of TestStand, you get the conflicts rather than automatic propagation in cases in which the verison of the type in the type palette would get overwritten by the version of the type from a sequence file.

 

3) If you do not use type palettes, unintended type propagation and non-deterministic versioning of types is very likely. Whichever file has the highest version of the type will cause all other files loaded at the same time as that file to use that version of the type. So depending on which sequence files are loaded when a particular file is loaded, you might end up with a different version of the type each time you run the file (i.e. it's somewhat non-deteministic which version of a type a particular file will use if you don't use type palettes).

 

4) Type conflicts with type palettes can be avoided if you always make sure that the latest version of the type is in the type palette file. That's precisely what the type palette is for in this case, to guarantee that if you accidentally load a file with a type that is newer than expected, you will get a conflict, rather than virus-like unintended propagation. You might think you are avoiding that by not using type palette files, but the reality is exactly the opposite.

 

Given the above, what are the issues you feel outweigh the advantages (i.e. protection from virus-like propagation and deterministic versioning of types) of type palettes that keep you from using them? What are the causes of the difficulties you are facing? Is it perhaps due to a misunderstanding or misapplication of type palettes, or do they behave in someway which makes things harder for you?

 

If type palettes are causing problems for people I'd like to come up with a better alternatively than just relying on the type definitions in the files, because relying on the ones in the files can lead to unintended type propagation and non-deterministic behavior which I think no one expects or wants.

 

-Doug

0 Kudos
Message 8 of 24
(2,483 Views)

@~jiggawax~ wrote:

There are several problems with deploying type files.  Here are a few:

 

  1. It is unnecessary.  You already have the type defined in your sequence file.
  2. It can cause run time errors.  If the type is created for a specific module and you change the type and the module doesn't update then you can get run time errors.  Because the prototype has changed.
  3. It is an extra layer of maintenance.  Now you have to maintain on the dev environment and the development environment and spend time re-deploying those files.
  4. A lot of times development is done on deployment machines (because of instrument constraints).  If you are just trying to make a quick change in legacy code but your environment is trying to load a newer type you now have to account for all those instances.  What was a 10 minute update could quickly turn into a 3 day project.

In my experience I have found it is best not to deploy them because issues are reduced dramatically.

 

Anyhow, take it for what it's worth but that's my 2 cents.

 

Regards,


1. But you won't necessarily get the version of the type in the file when you use it, you will get the highest version of the type that any file that is loaded at the same time as your file uses.


2. It should only cause runtime errors in cases in which you would have gotten virus-like type propagation if you are using the default settings for types. Automatic type updating should still happen, you just have to make sure that the highest version of the type is in the type palette file.

 

3. It centralizes the type maintenance. You don't have to worry about what version of the type sequence files were last saved with, rather you can rely on the fact that all sequence files loaded on the machine will use the version of the types in the type palette files. This ensures that all substeps can expect the type instances to be based on that latest version of the type, simplifying maintenance and development of substeps. What is the difficulty with deploying a type palette file? Perhaps that could be solved with improvements to the deployment utility?

 

4. How does relying on the types in the files solve the problem? You won't necessarily get that version of the type when the file is loaded and now you will potentially have multiple versions of your type with the same version number. Why is it a 3 day project to update the type in the type palette file instead of in several sequence files? It seems like having a single source for types would be simpler.

 

Thanks for any info in helping to understand the problem.

-Doug

0 Kudos
Message 9 of 24
(2,479 Views)

chilidog,

 

We have about 30 developers pointed to the same public folders on our SCC.  The link works fine for us.  Did you restart TestStand?

 

The other thing you can do is check  that your search directories are correct in teststand.  The 2 entries: TestStand Public Directory and Public Component Directory should be pointing to your new location.  If they aren't then you did something int he registry incorrectly.

 

BTW- I noticed that your picture of Station Options>>Preferences is showing the config directory.  Do not be confused.  The public directories are totally different than the config directory.  

 

If you are using Win 7 you need to look in the Wow6432Node location in the registry.  That is where you would need to update it.

 

Hope this helps,

jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 10 of 24
(2,478 Views)