Automatic type version handling

[jopexa]

Hi, is there a way to set my Models and PluginModels to accept the type versions that is already loaded into TestStand?

The source of the problem is that we provide a software to work with TS, and this can be used localy in the office or in a factory somewhere in the world. Some changes had to be done in both Processmodel and model-plugin files to get it to work. But while doing so some of the types must have changed. The installation works on mint condition PC:s that has never ran TS before, but our old teststations are screaming every time you try to start a new test because of type conflict.

It is no big problem, for me, to just open up the files on the station and re-save them, but there is a huge risk for human errors when it comes to the factory workers. So, is there a way to change my new model files so they will just go with whatever type version that exists on the station? I have tried to change them back and change them to lower versions but nothing helps.

The problems origin is probably that they were opened in later versions of TS and then saved and then resaved to lower versions.

-Jopexa

[bienieck]

You can set Allow Automatic Type Conflict Resolution to Always in Station Options.

[jopexa]

Hi Michał,

that is a solution, but not a solution for my problem. As said, we want eliminate existance of human errors, however small they are. With that said, when I mentioned that we can't edit the 'cfg' directory I meant that we can't change anything, on the PC, that requires manual labor. I know, this sounds very nitty picky, but that is what my work mission is. So going in and changing the station options is also a big no. The expectations is that whenever someone downloads the software, with the model files, it will instantly work. Most of the people, that use it, got a thumb in the middle of the hand when it comes to computers, IT and TestStand. Some doesn't even know that they are using TestStand or what TestStand is. My boss told me that some of the costumers needed help, over the phone, just to log in. It has gone so bad that our addon is even hiding the Configuration menu from the users, as they have sometimes touched buttons they should not touch which has created some really bad scenarios. I also really don't want to travel abroad, or sit on phone/mail with a 30-50 year old foreigne boomer who barely speak english, just to find out that it is the model files that is causing trouble because someone didn't do that during the installation (as sometimes TestStand has ignored my model-plugins because of type conflict).

I thank you for your time and answer, but this is not a solution to my problem, but it might help others who got almost the same problem.

-Jopexa

[bienieck]

Hi again,

Let's clarify couple things.

You want to have a clean TS installation and on top of that you want to add custom process model and plugins.

Those files use non-default type definitions which propagates changes around your system. This propagation requires from you manual type conflict resolution.

You don't want to add changes to the station options to allow automatic conflicts resolution.

Do you use custom TS environment? Do you use sequence editor or OI? Do you use bat to start the app?

I believe your problem can be solved but you will end up with non-default setup anyway.

[jopexa]

Hello Michał,

Thank you for your reply. I will try to clarify as much as possible.

You want to have a clean TS installation and on top of that you want to add custom process model and plugins.

Kind of. We want that whatever if you got a mint, non spoiled, fresh installation or you got a grotesque mess, that can have been running our previous versions or not, to be able to install the .msi, which the model files are included in, without any problems.

Those files use non-default type definitions which propagates changes around your system. This propagation requires from you manual type conflict resolution.

It was my belief that TS just used the ones you specified, as if you specify that you want to use batch.seq in the public folder, as an example, then it runs them and use them as a core. I am sorry if my understanding of this concept is totaly warped.

You don't want to add changes to the station options to allow automatic conflicts resolution.

Yes. We got machines from 2010, and maybe earlier, still running in factories spread over the world. The requestment is, if possible, that only changes to the installation package, both out program but also sequence files, can be modified. Or to be more exact, the only interaction that is allowed to happen, from us or the factory worker, is running the .msi file on the computer and also a restart of the system.

Do you use custom TS environment? Do you use sequence editor or OI? Do you use bat to start the app?

We are using the TS API to add a TS execution window. So the users can only see the steps in the sequence and the results of each step, but they cannot edit anything. It is written in c# and uses a normal exe file, sorry if highened your expectation of the advancement of the program. We at the office provide the sequence files aswell as the software, so most of the users have no clue that they use, I guess we can call it an extension of, TS or what a sequence file is.

Our "only" requirement is that the model and model-plugin files in <TestStand public> can be used without ever causing a type conflict. I would say equally to when you sit in Java 7 and import another Java 7 module into the project, as long as it is written in Java 7 then there should be no problem. If it is written in a version bellow 7 then you can count on some obsolete functions and etc, that you need to change, and if above then the risk of it not working exists. Because in the end; everything is in TS version 5.0, so it feels very strange that you can't set the files to go with the flow and become the same version of what the system is using without changing system options.. I have been looking here and there, but everyone seems to say that you need to do it manually, which is something we, espacially the higher ups, want to avoid.

-Jopexa

[bienieck]

So you want to provide the end-user an MSI file that will install the custom process models and plugins in the <TestStand Public> folder.

Are your station options configured to use the model from the public folder, or does each test sequence specify it individually? I assume you have plugins configured to use the one from the public folder (<TestStand Application Data>).

Can you show the type conflict window you see after installation (this is not necessary but might help)?

I think I know what is going on with your targets:

You install an altered model/plugin. There are changes in type definitions saved in those files. So, the model/plugin will load a newer version, but test sequences were made using old type definitions (probably model/plugin types instances are saved in them; e.g., they overwrite process callbacks), so when you try to run them, the model is loaded, and you see a type conflict. This is practically unsolvable because if you change the type definition used in multiple places, in all these places, the definition must be adapted (so the file will change).

So, even if you open your test sequence after installation of the new model, you will get automatic type conversion (you will see a plus sign where you normally see a dirty dot when you modify a file).

You could run it, but it will ask you to save the file (unless you disable this option in the SeqEdit options), and it will also ask you to save it when closing.

I think the problem is that whenever you have an automatic type conversion, even if it is expected, you are forced to decide whether or not to save the file after conversion (which is a safe approach, IMO). In your case, I think you need to create a script to open every sequence file, let the TS do the automatic type conversion and save it. This script would need to be run after the updated model/plugin is installed. Also, after such automatic conversion, running a sequence analyzer (which can be done with a CLI) would be beneficial. I'm not aware of such a feature out of the box. But I guess if there is, it would be available in TS Deploy Utility (but I've never seen such a thing, TBH).

[jopexa]

Hi Michał,

yes. The software, in our installation package, is built to load the Process Model File in the <TestStand Public>, which calls the ModelSuport which in the end calls the plugins.

And yes, you have hit the head on the nail. The main problem was that someone had changed the UUT type to be version 6.0.0 and the BatchSocket to 5.0.0, and everyone rolled with it. I had been misslead to believe that the UUT would be 5.0.x and the BatchSocket 5.0.x something, like how they are in our respitory on svn. I changed them to those version and it works for our test stations. Sadly I didn't read your reply before I did an hour investigation of this yesterday.

The script would have worked in most scenarios, the problem is that we got over 1000 of tests and they are on a server. The software download them whenever you want to run them, so the script would be required to handle database connection and such. And the .seq files are on different sevrers aswell. But that is absolutely something that I will keep in mind if we get this problem again.

We are not running TS Deploy Utility, as we deploy the software with Wix, but I guess there could be something in it for this problem maybe.

Just to make sure, are you sure there is no feature to make your files act like submisive when it comes to type version. Like setting a type version to '5.0.x' to tell TS that this type can be used as any kind of that type that has the version 5.0.x, and if there would become a true type conflict (a variable missing or such) then it's our fault and we have to fix it? I am thinking like in Java script and how you can put a String, an Integer and an image object in the same list but you will get a problem if you try to use anyone of these like a database connection. As long as you use them in a generic way for objects, like printing their value or move them to a different position, then everything is ok.

We are totally fine with errors and crashes to happen in the office, as we can fix them, but we can't have that happen in the factories, as they have no ability nor knowledge to fix it. (I am not so much better myself, but I have been sitting with TS at least for a couple of months)

Thanks for your reply.

-Jopexa

[bienieck · Accepted solution]

---

@jopexa wrote:

The script would have worked in most scenarios, the problem is that we got over 1000 of tests and they are on a server. The software download them whenever you want to run them, so the script would be required to handle database connection and such. And the .seq files are on different sevrers aswell.

---

You will have a much more complicated updating procedure in such a setup, as you already know. I don't have any good idea out of my mind. However, I will try to figure out something during toilet breaks 😄

---

@jopexa wrote:

Just to make sure, are you sure there is no feature to make your files act like submisive when it comes to type version. Like setting a type version to '5.0.x' to tell TS that this type can be used as any kind of that type that has the version 5.0.x, and if there would become a true type conflict (a variable missing or such) then it's our fault and we have to fix it? I am thinking like in Java script and how you can put a String, an Integer and an image object in the same list but you will get a problem if you try to use anyone of these like a database connection. As long as you use them in a generic way for objects, like printing their value or move them to a different position, then everything is ok.

---

Run this in cmd:

hh.exe mk:@MSITStore:%TestStand%\Doc\Help\tsfundamentals.chm::/InfoTopics/Types_Revision.html

It shall run TS help on a page regarding type conflict resolution. You will understand that TS will either report the conflict or automatically resolve it, but both cases will end up with some user interaction. It seems that TS calculates some checksum or something to compare types. It doesn't matter if there are no functional changes - add only a comment, and you will have a type conflict to resolve ¯\_(ツ)_/¯ You can try that yourself.

[bienieck]

BTW I thought that this JavaScript feature you described is not recommended. I'm not a JS man but isn't it a bad practice to specify dependency with wildcards in version?

[jopexa]

Hi

You will have a much more complicated updating procedure in such a setup, as you already know

Yes, the old ones have really engineered something great and complex here. There seems to be something that always blow up here or there in our network of softwares in the package.

BTW I thought that this JavaScript feature you described is not recommended. I'm not a JS man but isn't it a bad practice to specify dependency with wildcards in version?

Well mostly it was an example. Pretty sure, when it comes to version, you just run a script and the interpreter tries to handle it as good as it can and breaks when it can't. The feature isn't the greatest, ofc, but it got some of its positives too. If you have a list of strings, and always use it as a list of strings, then it is bad practice to put in an integer in it. But say that we have an object which has alot of different type mixed here and there, like a web page or a report with grapsh and images, then it can be pretty handy to be able to handle it as just on list of objects, as you can put everything in the order they come. That ofcourse requires you to keep it in mind that the object you are handling, from the list, can be a paragraph, a header, an image or a table of content. In most of the higher level languages, as well as the mid levels like java and c#, there are ways to represent data objects as an generic 'object' type.

I am also pretty sure that in the OOP doctorine you are taught  that you should try to express your objects close to the core as you can, mostly for changeability and keeping everything as independent as possible.

It seems that TS calculates some checksum or something to compare types. It doesn't matter if there are no functional changes - add only a comment, and you will have a type conflict to resolve ¯\_(ツ)_/¯ 

yeah, I am fully aware of it. And it is a pain in the arse. I will take it as an answer to my original question. It is a real bother, but it may be a very good reasons why NI has chosen to do it like that. Then again they are the same people who thought that TS 20 and 21 should crisp the rehtina of the users and who thinks that reinstalling TS to get back the original process model files, instead of having an online library with them, are good concept ideas.

Thank you for your time, help and insight Michał. I also wish you a jolly weekend.

-Jopexa