Teststand best practices architecture for communicating with TCP instruments

[aSquared]

Hi,

I am using Teststand 2014 and LabVIEW 2013 SP1 as the module adapter.

My Teststand sequence file includes communication with 3-5 different instruments via TCP/IP.

Such as Spectrum analyzer, generator and other RF measurement devices.

There are many steps located in subsequences that implement code to communicated with these devices whether to fetch , query or write.

What is the best architecture to implement this program ?

As I can see it there are many possibilities, such as :

1. Launching a subsequence as a new thread in the Sequence Setup. This subsequence calls a VI that dynamically register for events/queue that can be launched from any step. (in this case there is a VI running in the background that can perform Write/Read/Qurey to the instrument and he is triggered from any step using an event or dequeue element)

This option can be duplicated for any instrument or only once for all of the instrument with prioritizing the event queue.

2. Creating a communication reference in the Setup of the Main Sequence. And passing it to any step that need it. (there is also the question how to pass this reference… in Teststand globals or in LabVIEW queue).    

another 2 small questions that I encountered -

Is using LabVIEW queues and notifiers in TS steps and obtaining their reference (in the LabVIEW code) by name is considered best practices ?

If I would like to run only one VI in a new thread, should I use a new subsequnce and set it as a new thread or use the Run VI Asynchronously ? what are the differences ?

[crossrulz]

I use Action Engines to hold my VISA Sessions and just write my LabVIEW VIs to use those to send commands and read data.  Any returned data can be analyzed in the VI or passed on to TestStand as a step result.  You just need a sequence to run at start up to initialize your Action Engines and another one to close them.

[aSquared]

Hi crossrulz, 

Thank you for you response,

I have tested both options - 

1. Having the connection reference to the instrument held in a new thread sequence or loaded VI using FGV/AE to Write/Read/Query 

2. Storing the connection reference to the instrument in a Teststand Fileglobal and passing it to steps that need to perform the Write/Read/Query

Both options are working fine.

I would like to think together about the pros and cons of using option 1 vs option 2 , regarding  to -

a. future changes of the code

b. maintenance/debugging

c. what is right for TS architecture (is it ok to use LabVIEW FGV's in TS ??)

What do you think about the option of a custom Callback Sequence that will perform the communication?

Is it too much ? 

[Dennis_Knutson]

As an alternative, I created a custom step type for each instrument following the exact same architecture as the built-in IVI steps, including an edit pop-up.

[aSquared]

Hi Dennis,

Can you please elaborate more ?

What are the advantages of doing it ?

Can you send a screenshot ?

Thanks 🙂

[Dennis_Knutson]

Sorry, I don't have TestStand on my pc right now but you can simply drop an IVI step into a sequence and look at the edit step to get an idea. Then look at the step properties. You might even find that some of your instruments have an IVI driver.

I did this do that the developers would have an interface similar to what already existed from NI and would not have to learn something new or do any development in LabVIEW. They only had to learn TestStand.

[RaviShrigiri]

Hi

A custom step type provides a simplified way of using the device ( without having to know much about the TCP commands or hardware detail )

You can try using existing custom TCP step types :

https://forums.ni.com/t5/Example-Code/TCP-Client-Custom-Step-in-TestStand/ta-p/3664471

This example is specific for the TCP protocol.

You need to make something similar but specific for each of the instrument.

Reference to create a custom step type :

https://www.ni.com/en/support/documentation/supplemental/08/teststand-custom-step-type-development-b...
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9LJSA0&l=en-US

Hope this helps.

Ravi