Is the C/CVI Adapter to be deprecated?

[Grasshopper]

My team has been using TestStand 2.0.1 for 10 years and just now upgraded to TestStand 2013.  I noticed the default code templates don't use the C/CVI standard prototype adapter for C/CVI steps.  I read somewhere it's considered legacy support so what I'd curious about is if that adapter is going to be deprecated any time soon.  Thanks.

[~jiggawax~]

This came out a couple years back: http://forums.ni.com/t5/NI-TestStand/Does-anyone-currently-use-the-CVI-adapter-to-directly-call-c-li...

Maybe it's related?

Regards,

[Grasshopper]

Thanks for the reply.  It's related but not what I'm after.  That refers to calling source modules directly whereas we already utilize DLLs.  I'm more interested in if the C/CVI standard prototype will be changed.  I.e. tTestData * and tTestError * will not be available.  The default code template for a LabWindows/CVI multiple numeric limit test step doesn't utilize them.  

[Norbert_B]

I dont know much about TS 2.0, so i dont know the recommended (and supplied) code templates for CVI back then.

Nowadays, NI recommends the developer to create step code modules to be very much independent from TS, so passing values between TS and the code module is recommended to be done by using standard datatypes for parameters. Using the SequenceContext as IN parameter to the module and using the TS API in the module to read/write other values is still possible, but not recommended.

That being said, there are certain exceptions where using the SequenceContext in the code module is appropriate or even required (e.g. "Termination Monitor"). But for most cases, please remove that parameter from your code modules (as long as applicable).

Regarding "Deprecation" of the CVI adapter: I never heard of anything like this. Sure, NI will change things here and there from time to time, but in general, CVI is still ongoing and fully supported.

Norbert

[Grasshopper]

Norbert, thanks for the reply.  The test code my team writes pushes complexity of tests into the code rather than up in the sequence.  I.e. equipment manipulation is done in a test vs an IVI or similar test step setting something.  Even if we moved all equipment details into the code I don't see how we'd be able to not have the sequence context.  The reason is we'd prefer a consistent test interface and some tests will require accessing Parameters, Locals, other step results, etc.  Is there another way to accomplish the same thing?  Thanks.

[Norbert_B]

I am not sure about the goal of your question.

Despite that, my answer is the following:

Looking in the changes NI did to most adapters, NI tries to encourage developers to create modules which are independent from a specific interface (in your case: TS because of "SequenceContext"). This improves development, test and re-use of modules.

That being said, NI still keeps upward-compatibility as long as possible, so passing SequenceContext and using TS API within the code modules is still a valid way for data exchange. And i don't see anything which should skip that opion in the long term (as said, the Termination Monitor requires the SequenceContext and TS API!!!).

My understanding is now that you have seen a different code template for CVI modules in TS 201x compared to TS 2.0. As i told you, NI encourages you to drop SequenceContext as parameter in the future, but if you prefer to go that road you can still keep moving this way....

Norbert

[Grasshopper]

Our team probably utilizes TestStand differently than most as we're comfortable writing code and to simplify the sequences for reviews the steps are basic.  You can boil down a sequence to the following: setup checks custom operator inputs, each step then sets up a specific piece of equipment/unit/etc. then each step in the main tab is a multiple numeric that calls a function in a CVI compiled DLL ( to be changing to Visual Studio C++ compiled DLL ) followed by each step in cleanup cleaning up whatever was setup in the setup steps.  All equipment/device manipulation is inside a code module called by a test step.  There are no IVI, ActiveX, or other controls manipulating equipment in the sequence. Loops are nearly non-existant in TS. It's a test runner essentially.  Each test step is considered standalone except for dependencies on equipment and shared TestStand variables ( Parameters, Locals, etc. ).  So, test 1 might access equipment A and B, read a Local variable, do a measurement and return result(s).  Test 2 might access equipment B and C, read a Parameter, do a measurement, and return result(s).  Each step indicates the occurrence of an error, too. Equipment handles and init counts are in TS currently.  We're considering pulling them into the DLL but data in Locals ( populated by a Limit Loader step or manipulated by PreExpressions or the like ) isn't accessible without the SequenceContext.  If code modules are written that are completely self-contained either you'll have inefficiencies from each step doing setup/cleanup and you have no access to Parameters and Locals other than PreExpressions for a given test, correct?  How would you make a separate code module for reuse that isn't dependent on anything in TS without having each code module be so basic that it takes 1-n steps to do something in TS which makes TS sequences longer and harder to read/copy? Am I missing something?  

[Norbert_B]

From reading your post, my first impression is that your code modules are

- convoluted

- 100% dependent on a TestStand environment

Let's take a close look on "an ideal world":

In the ideal world, i would have a set of basic functions which are written in any programming language with well defined interfaces. I could take these basic functions ("library") into any project developed in literally any programming language as they are not depending on anything except generic parameters. No foreign API used in these library functions.

As they are focused on only one task per function, they are highly re-usable and maintaining them (e.g. bug fixing, adding new components) is very easy. The modules are loosly coupled and have a high cohesion.

In the real world, developers tend to break coupling and cohesion by creating basic functions which depend on another. The functions use foreign APIs to handle data and parameter. The functions do not contain only a single task, but loads of different tasks; still, they are "ONE" module. These are hard to re-use, debugging gives the developer a headache and adding new stuff is horrible and might break things eventually. These modules have high coupling and low cohesion.

The goal for TestStand code modules should be "the ideal world":

- Use parameters not depending on a foreign API (in this case: TestStand)

- Only perform a single task in the code module (e.g. acquire data). Do not add other functions, first of all EVALUATION of data as this should be done by TestStand

- Remember that TestStand is a sequencer: Code modules should only sparsely depend on parallelism in their own (read: depending on other modules running in parallel) and block as short in time as possible

- Keep readability: This refers to code design as well as naming connventions of functions and parameters

Norbert

[dug9000]

---

@Grasshopper wrote:

My team has been using TestStand 2.0.1 for 10 years and just now upgraded to TestStand 2013.  I noticed the default code templates don't use the C/CVI standard prototype adapter for C/CVI steps.  I read somewhere it's considered legacy support so what I'd curious about is if that adapter is going to be deprecated any time soon.  Thanks.

---

There are no plans to deprecate the CVI adapter's support of the standard prototype (the new CVI adapter supports both the standard prototype and more flexible specification of prototypes). That said, I would imagine most users find the more flexible prototypes allowed by the CVI adapter in newer versions of TestStand to be easier to use since they can pass exactly the parameters they want to in and out of the dll without having to use the sequence context or TestStand API. I'd recommend you take a look at how flexible prototypes work to see if they might be an approach that would help you improve developer efficiency in the future.

-Doug