Multiple instruments; same test. Best plan of attack?

[F1_Fan]

I'm looking for some information on design structure dealing with multiple instruments that do the same thing but require different command sets. Specifically I have an application running tests via VISA GPIB using an Agilent PNA. My current application uses a queued state machine with two loops; one taking care of the GUI and another taking care of the states; works like a champ and is easy to add new tests. But I have been asked to migrate the current tests to different flavors of network analyzer specifically old school HP8510 and some non-hp gear. Some tests are very complicated and have a couple dozen steps with numerous sub vi's to take care of all the commands and data formatting. We do not want separate applications; I have to identify what is connected and sequence the test accordingly to attain the correct results. 

I'm looking for links, suggestions, or recommended reading to deal with such things and to maintain maintainability.

What I have been able to find is hit and miss with some reading pointing towards using a separate state-loop for each instrument and others just added more and more states to existing state machine.

All opinions / ideas welcome.

-Chris

[seVEMes]

Are you accessing all of the devices through one GPIB card? If so then I would suggest the second option of adding more states but this could get complicated. You could try two state machines in one loop but I doubt that would work.

If you are using multiple protocols I recommend multiple loops.

Are you running multiple machines at the same time? If not you can have multiple loops even if it is the same protocol but you will have to put each loop in different cases of a case structure. I recommend this because it would be the simplest approach. For this you may want to set a wait for a user input before it starts. If you are going from one machine to the next you can put all of this in a large overall while loop.

[James@Home]

F1_Fan

I have developed an application that might be similar in nature, but different type of instrument.  My situation involved thermal testing and the need for the software to function with many different thermal chambers.  I created a set of VIs for the main chamber control functions: Initialize Chamber, Set Temperature, Monitor Temperature, Shutdown Chamber, etc.  Each of these sub-VIs has a case structure with cases for each different chamber types.  The top-level software has a selection for initialization that reads an INI file that includes a key for chamber type.  This value is then used as an input to the chamber control sub-VIs.  This method kept my block diagrams clean and didn't result in a lot of duplicate code for all of the other functions that are the same regardless of chamber type.

Hope this suggestion is useful.

Good Luck

James

[mikeporter]

The answer lies in the basics of good design - specifically a concept called "Information Hiding". In this case the information you are wanting to hide is the instrument (and commands!) used to perform a particular function.

The key is to create a set of function drivers that look at the required functionality from the standpoint of what needs to be done, while ignoring how you are going to do it. Now create a version of this function driver that uses each of the potential instruments to perform that function. To call the correct function VI write a caller VI that looks up the instrument installed on the system (you can use an ini file, database, whatever) and using that information dynamically calls the correct version of the function.

One other thing to consider is with the acceptance of standards such as SCPI, you might not need different VI to control different instruments of the same type.

Mike...

[F1_Fan]

Good suggestions.

SCPI is great but some of the instruments are 20 years old and things like getting bandwith numbers are more complicated in the older equipment. I'm still fighting with people to stop using low level GPIB commands and just use VISA.

My understanding of the replies lies in writing a subset of vi's for each piece of equipment while reusing the common commands (Like writing an overloaded function in .NET land?).

A simple flow diagram of what would occur would be as below if I'm understanding the suggestions -

- Front panel for user to select required test.

- Query what instruments are connected and decide if hardware is available to run such test.

- Using VI's libraries I will create to perform each test; select the proper set and run the test. (I would still use a QSM type design to easily facilitate changes down the road).

- Everything would be invisable to the end user; they are just selecting a test; all front panels will be standard regardless of instrument. They would only differ by the selected test.

Am I on the right track? I'm a VB.NET transplant trying to not get on the "wall of shame" of labview code. LOL.

-Chris

[Ben]

---

F1_Fan wrote:

Good suggestions.

SCPI is great but some of the instruments are 20 years old and things like getting bandwith numbers are more complicated in the older equipment. I'm still fighting with people to stop using low level GPIB commands and just use VISA.

My understanding of the replies lies in writing a subset of vi's for each piece of equipment while reusing the common commands (Like writing an overloaded function in .NET land?).

A simple flow diagram of what would occur would be as below if I'm understanding the suggestions -

- Front panel for user to select required test.

- Query what instruments are connected and decide if hardware is available to run such test.

- Using VI's libraries I will create to perform each test; select the proper set and run the test. (I would still use a QSM type design to easily facilitate changes down the road).

- Everything would be invisable to the end user; they are just selecting a test; all front panels will be standard regardless of instrument. They would only differ by the selected test.

Am I on the right track? I'm a VB.NET transplant trying to not get on the "wall of shame" of labview code. LOL.

-Chris

---

Hi Chris,

This is similar to a Q posted on LAVA earlier this week that can befound here. In that thread Aristos Queue (father of VLOOP LV OOP) outlined some classes to utilize Dynamic Dispatching (choose the sub-VI to run based on the class selected). Conciering your background, that thread may work for you.

Have fun,

Ben

[F._Schubert]

I did that challenge for a small set of functions for several differenet devices. Here the basic architecture:

Top Level:

Init, Close, Set Volt, Get Volt

They all wrapp the same SubVI:

'Container AE'

An AE (Action Engine) with the Actions (Init, Close, ...)

In Init there is a OpenVI with the reference to the device-specific AE, which is called in all states the same way as this vi. In Close there is the additional Close primitive.

 Device Specific AE'

This calls the device specific driver VIs, same Connectors as 'Container AE'.

 For Container AE as well as Device Specific AE a template was created befor implementation.

A seperate VI I call Architecture will contain all VIs mentioned, so also for every device specific AE the VI, to check if I add an Action to the interface, that all device drivers are updated.

That design was inspired by the idea to have an 'Interface' as in OOP.

Coding in LV 7 you are not having any native OOP capabilities. I 'enjoy' it, becuse you are focused on the concepts of OOP and how to implement it in the wire-world and not on talking the same tech-language of calsss and object (wich is one of the concepts BTW).

Hope it helps and others share there ideas on this...

Felix