type file managment with source code control

[dug9000]

---

@j_dodek wrote:

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

---

Type virus like behavior should no longer occur in recent versions of teststand as long as you use type palette files, if you don't use type palette files then it can still occur. There is a new station option that exists to avoid the type virus like behavior by default in recent versions of teststand when using type palettes. Perhaps you hit issues with virus like type propagation in older versions of TestStand which did not have the new feature?

If you are getting type conflicts, it either means your types are marked as modified, you aren't using type versioning, or you have a sequence file with a newer version of the type then your type palettes.

Perhaps the issue you are facing is that you'd like to use a different version of your types depending on which sequences are loaded. Perhaps such a use case is not well supported by type palettes. In such a case how do you make sure your substeps work with all versions of the types involved? Is your substep code backwards compatible? Do you not use substeps?

My main concern with you all not using type palettes is that you might not realize the risk of unintended propagation you are getting as a result. Perhaps there is a better 3rd way to deal with types that would address those concerns yet still avoid the inconveniences you faced with type palette files.

-Doug

[~jiggawax~]

Dug,

First of all we don't ever load 2 automations at the same time. (our definition of an automation is the MainSequence file and any dependencies).  If you think about an automation as a stand alone application then it makes sense not to rely on some type in a different file.  That is how it is done in most software applications.

The only time we would ever have conflicts is if our baseline package (i.e. the process model and its dependencies) ever changed a type.  Well, to solve that we develop against the baseline package that is on the deployment machines.  We can roll our SCC back to the timestamp in which the baseline was rolled out.

I think you missed my point about code modules.  Especially the LabVIEW code modules.  If a type in the palette changes, now your container that was being passed to the VI no longer matches up with the cluster connected to the connector pane.  This causes run time errors.  It is bad. If we were to centralize our type palettes this would happen all the time.

In summary:

On the development envrionments we absolutely have it centralized.  In the deployment environment we like to think of each automation as a stand alone package.

Sorry chilidog... you have spurred a great conversation about type usage... 🙂

[dug9000]

Sorry for the thread takeover chilidog. Let us know if you are still having problems getting the directory changed. This secondary thread is an important one though so I hope you don't mind. We can create a new thread for it if needed, though I think we are almost done.

-Doug

[dug9000]

---

@~jiggawax~ wrote:

Dug,

First of all we don't ever load 2 automations at the same time. (our definition of an automation is the MainSequence file and any dependencies).  If you think about an automation as a stand alone application then it makes sense not to rely on some type in a different file.  That is how it is done in most software applications.

The only time we would ever have conflicts is if our baseline package (i.e. the process model and its dependencies) ever changed a type.  Well, to solve that we develop against the baseline package that is on the deployment machines.  We can roll our SCC back to the timestamp in which the baseline was rolled out.

I think you missed my point about code modules.  Especially the LabVIEW code modules.  If a type in the palette changes, now your container that was being passed to the VI no longer matches up with the cluster connected to the connector pane.  This causes run time errors.  It is bad. If we were to centralize our type palettes this would happen all the time.

In summary:

On the development envrionments we absolutely have it centralized.  In the deployment environment we like to think of each automation as a stand alone package.

Sorry chilidog... you have spurred a great conversation about type usage... 🙂

---

I think I'm understanding the problem better. The types you are referring too aren't step types, or generally used types, they are simply data structure types for cluster and/or struct passing. Perhaps in that use case what would work best would be to have local types that only apply to the sequence file. That way there would be no possibility of type propagation or conflict between two sequence files. Perhaps if we added the notion of Local types to teststand that were only visible/useable in the sequence file in which they reside, that would address your use case better. Perhaps if the button that creates the corresponding data type for a cluster used such a Local type by default that would work out naturally. Does this sound like a good idea? If so, I will record this as a possibility for a future enhancement to TestStand. For step types I would still recommend putting them in type palette files.

Another idea would be project/workspace specific types/typepalettes. Would that be something you would like or prefer?

-Doug

[~jiggawax~]

Personally I like types the way they are.  You just have to know what you are doing.  I think that you have the same issue in TestStand with types that you do in any other language.  Know where the source is and understand who is using them.

If any of our developers even thing about touching the native types we chop their fingers off.... haha.

[chilidog]

Hi Doug,

Yes this is how I'm currently using types.  When I create types I'm very careful about what I'm storing in the types pallete vs what I store in the sequence file.  I think this feature would be very useful

[chilidog]

---

Sorry for the thread takeover chilidog. Let us know if you are still having problems getting the directory changed. This secondary thread is an important one though so I hope you don't mind. We can create a new thread for it if needed, though I think we are almost done.

-Doug

---

It's quite alright, this is a good discussion and I'm glad I helped stir the pot, it's very informative

I'd like to get back on topic now

---

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,

---

Hi jigg

yes this worked and I saw my new location when I looked at the search directories but now I'm a little confused.  What is the cfg folder and also what about the components.  Are these locations additional folders that I should also be putting in my SCM workspace?

Chilidog

[chilidog]

guys this is touching on another topic that I would like to explore further.  I think it makes sense to start another thread.  how do we do this? should I start another thread or would somebody else like to do that?

[~jiggawax~]

---

Hi jigg

yes this worked and I saw my new location when I looked at the search directories but now I'm a little confused.  What is the cfg folder and also what about the components.  Are these locations additional folders that I should also be putting in my SCM workspace?

Chilidog

---

The cfg folder contains configuration information for the bench such as Station Options information, Search Directories, Station Globals, Report Options, Users.ini, Database Options...etc...

The Components folder is a sub folder in the public directory and contains code for certain TS components such as the process models, step types, etc... That's why in the search directories it is searching the subfolders.  So that TestStand can find all of the code modules for your process model.

When you deploy there is an option on the first tab that allows you to deploy your public directory.  That will deploy all the components as well as other parts of the public directory.

However, your cfg folder is not an option in the deployment utility.  Therefore, you must deploy those separately.  By default TestStand will create the cfg files when the engine gets executed. So if you want you could technically go delete your testexec.ini file and start up TestStand.  It will create a new default one.  Generally you have different settings for development and deployment.   So you need to add the cfg files to your Workspace if you want to deploy them. 

What we do is deploy several packages.  

So we will create a build with the engines (LV and TS), drivers, cfg files that we have set up for deployment machines and the user interface.  

Then we create a package with our customized process model and any public folder stuff.  

Then we deploy our automations with the sequence file and any code modules.

That way we can quickly create automations without having to worry about packaging up all that other crap that will be the same for every automation.

Anyhow, hope that helps,

[chilidog]

Hi Jigg,

so if TestStand creates a default cfg folder in the default location how can I redirect the cfg folder to my workspace?  Are you saying I need to point my workspace (or at least a workspace specific to the cfg folder) to the default TestStand cfg location?  Everytime I try to point to my workspace in the station options dialog it doesn't stick.  the next time I restart TS it is still pointing to the default location