How do I make Step Types in the Type palette be "master" versions which all sequence files on a particular station should use? (since this only seems to "half work")

[kphite]

Yeah, I solved it the same way you did. Very ugly. And I had to figure it out on my own.

I agree that in a perfect world the step wouldn't need to change but unfortunately I can't think of everything when I build the step. Invariably when the new step gets used someone wants to add some new functionality or there is some quirk. Once you add the new function or fix the bug you have to go and update every instance of the step in every sequence and subsequence manually. Otherwise you lose the configurations of your steps. I guess if we keep this thread going long enough we will get a response from NI.

kph

[RichM]

Good to hear that I'm not all on my own then!
It seems from the discussion that there is no simple solution to make the type palette take precedence over the sequence file versions - looks like the only way is to open all sequence files, make the change to the prototype/change substeps in the type palette, make sure that you have clicked "Apply Changes to all loaded instances" and hope for the best that everything cascades correctly.
This is a real shame, as this has so much scope for sequence developers to be given a set of tools with which they don't need to know anything about the low level code (like IVI).
After discussing this with a collegue (non-TestStand programmer, currently) he suggested some tools which can effectively do an automated search and replace on a text file when opened (The .seq file is plain text) - this could do the trick (although not the most graceful of solutions)... anyone had any experience doing this?

[David_Jackson]

I have a similar problem, in that I have a set of custom step types based on ActiveX code modules that we call using the ActiveX/COM adaptor.  We are currently updating these code modules to .NET so need to change the adaptor for these custom step types to use the .NET adaptor.  Having done so and saved the new step type in the type palette I find that any sequences using these ignore the new type.  I have confirmed that the version used by the sequence and that specified in my type palette are the same type name and version number.  However, the type in sequence file still references the old COM adaptor.  This seems to be related to RichM's original problem where code module changes are not applied in type updates.

I'm now using TestStand 2010 SP1 and it has been over 6 years since this issue was raised.  Does anyone know if this has been addressed by NI yet, or if there is a workaround.  I have about 70 test sequences in our test frameworks that reference types based on ActiveX and do not want to have to open every sequence and manually delete and re-insert every custom step type call.

Regards,

David

[RayFarmer]

Hi,

Check out http://zone.ni.com/devzone/cda/tut/p/id/8300.

Use Pre- or Post-Step Substeps Instead of Default Module
Implement the code module for the basic operations inherent to the step type as a Pre- or Post-Step substep instead of as a default module step. Use the default module setting only when each instance of a step can call a different code module. The default module setting exists separately on every instance of the step, and TestStand does not update existing step instances by default when you change the setting on the step type. However, substeps exist only in the step type, and all instances of the step refer back to the substeps. Changes to substeps automatically affect all existing instances of the step type.

[dug9000]

Ray pretty much explained it. I'd just like to add a bit more details.

1) If you are using the default module to implement a behavior of the step type and the user generally cannot or does not customize the call specification (i.e. every step calls the same module and passes the same parameters) you should instead be using a post-substep and be setting the default module to designate the none adapter as the adapter for the step type (i.e. the step type does not use modules). Post-substeps are part of the type, as Ray said, and you will then not have this issue.

2) If you are using the default module because the parameters passed could be different for each instance or the module called could be different for each instance then what do you expect TestStand to do if you update the module in the type? What if the list of parameters is completely different? It could potentially do some sort of best fit heuristic on the parameters, but it might not give you the correct result and you will likely have to update every instance manually or by writing a program to do so anyway.

In most cases, a post-substep is a better place to implement step type behavior in a code module rather than using the default module setting. If you have additional questions or suggestions please let us know. If you have an idea for how to improve this, please consider posting it on the idea exchange.

Hope this helps,

-Doug

[David_Jackson]

Thanks Doug and Ray for your replies.  I now better understand how TestStand loads step types, which would have been great to know when I first designed our set of custom step type modules.  However, there was a nice tempting Adaptor selector on the General tab of the step type editor that to the uninitiated seemed to be an obvious way of specifying the module to use with the step type.

The modules I call have a ActiveX standard structure that forces parameters and variables to remain the same for binary compatibility.  Our new .NET assemblies are based on the same code and retain the same parameters and types.

I have tried Doug's suggestion by setting the adapter on the General tab to None, then adding a post step .NET call to the module on the substeps tab.  I have saved the new step type in my type palette (with the same name).  Sequence files using this step type load it OK (evidenced by changes I made in the comments field being detected and the sequence detecting the updated version) but these steps still have an ActiveX module reference.  None of my sequences referencing the updated step types seem able to remove this, which causes errors trying the reference the now non-existant ActiveX module.

Due to the number of files I have (which reference my set of custom step types) I need to find a way for these to automatically pick up the new modified step types with the adaptor changes.  Manually editing each sequence is not an option for us.

Regards,

David

[dug9000]

At the bottom of the step type properties dialog is a checkbox whether or not changes should apply to all currently loaded instances of the type.

0) Change the default module setting back to something other than none adapter.

1) Open all of the files (or a manageable subset if there are too many to load at once) which use the step type.

2) While the files are open, change the default module setting back to the none adapter and check the checkbox at the bottom of the step type properties dialog that this should apply changes to all loaded instances of the step type.

3) All the files that you have loaded should now have their module settings cleared out for this step type.

Hope this helps,

-Doug

[David_Jackson]

Thanks Doug for the step by step instructions.  Following these I was able to update step types in sequences loaded in memory at the time of the update.  Unfortunately, this is probably not a realistic solution for me.  I have about 40 custom step types, all of which need updating in approximately 70 sequences within my test framework.  Not all sequences use all custom step types, but I would still need to ensure that all 70 of them are loaded into memory at the same time, then follow your process to update all 40 step types!  Hopefully, neither myself or my PC don't crash in the process!

I have raised this as an issue with my local NI field sales engineer here in NZ.  What we really need is for something like the Sequence File update utility to do the hard work for us.  I have tried this but it doesn't work due the files not being loaded in memory.

I'm grateful for your assistance though.

Regards,

David

[dug9000]

It should be possible to write a tool that automates the updating. Hopefully whomever you are working with can help you with this.

-Doug