Some advice deciding what route to take in my design.

[NeilA]

I am newish to this forum I have done some more basic labview programming in the past and was taken on in my new job for my RF understanding. I have been thrown in at the deep end by updating an ols system based around HTBasic with LabVIEW at the same time the other software guys want to upgrade the surrounding architecture to bring it in line with a more modern approach so I would like to thank you in advance for any help/pointers that are provided. I would also like to appologise for the slightly vague descriptions of measurements and systems, i am unsure of the IP implications of being exact with my descriptions at this time.

I am beggining to plan the development of a test system that is going to use Agilent equipment to perform lots of different RF tests on a DUT. The test system will include switching matrices to control how the incoming/outgoing RF will be routed to/from the equipment. From a manual front panel control point of view, though not a walk in the park ,this should be acheivable in LabVIEW with my current knowledge (so you should consider this a black box).

The test system needs to be controlled remotely from a Web service front end as this service also links to a database, fileserver and the control systems for the device under test. I have researched the webservice information on the NI site and it all seems relatively straight forward (read not had a chance to play with it so may have more questions later LOL!).

Where the problem lies is that there may need to be a requirement for two of the test systems to be used simultaneously so one of the systems (master?) will provide an output while the other (slave?) performs the measurement.

I need to create some sort of asset managment/assignment where by I decide in advance (possibly on the PC that handles the webservice) which system is the output and which is the receive (master/slave). I also need to incorporate in my system a way to share the test setup information between 2 seperate vis running on 2 seperate systems.

I am guessing the easiest way to set the systems up at the start would be using a standalone master vi as a GUI that you can manually set all the flags for master/slave etc and this could be done at system build and calibration. The systems will always be on a LAN at run time but I am unsure how I can dynamically search the LAN and find the systems and assign their duties? Secondly I am uncertain the best way to store transfer the settings to the test systems, would a simple text file that each system checks at vi start be the best way?

My main concern though is the two standalone systems operating to gether to perform measurements. I am used to standard sequencial programming (command>read>result sort of thing). Would this type of system be as simple as a case select at run time (i.e. master true/false)? Or should I be looking into a more complicated but more stable programming standard? I feel that due to the many different types of test need lots of cases to cater for them all on each system if used stand alone, maybe it would be enough to have a couple of extra cases where on case is output and the other is receive. Is this to simple? Am I missing something with this architecture that would make this sort of implementation not work?

Many thanks,

I hope you can help sorry for the long post,

Neil Andrew.

[Neville D]

From a quick reading of your post, you need a lot of test management, so I would suggest you take a look at TestStand which will allow you to concentrate on developing the specific tests in LabVIEW, and leave asset management (using the instruments efficiently and in parallel etc) to the Teststand end.

It will also allow you to call your old HTBasic code if needed (maybe for initial debugging etc.)

PS. You might get your local NI rep to give you a quick demo of Teststand and its capabilities.

Note: I have never used it, but it seems like the tool for your application.

Neville.

[NeilA]

Thanks for the response.

You may well be correct suggesting TestStand thankyou. TestStand is already used here, it is currently the part of the system that is supposed to be changed to webservices. The intention is to make all the parts of the system above the RF Test system OS independant (hence webservices) with the RF Test System being a black box that can be commanded by SOAP commands. Shifting the current complicated use of TestStand down to the RF test system and removing the knowledge and understanding of the tests from the database and TestStand. In our current solution the use of TestStand is very convoluted, the system has too many layers and is balanced on top of a 20 year old programming language. I have had a small introduction to TestStand from my collegues and as I see it they do not use it in the way NI intended. So I may not understand how I could benefit from using it in the system I am putting together.

My first concern with TestStand is will I have the same problem with the TestStand where each system has to act as well on its own as it does together with a second test system? I am reluctant to suggest we have a seperate master PC with TestStand installed just to asset control the RF Test Systems i.e. I would like my final solution to be deployable as a rack with an embedded PC that can perform measurements on its own or with another rack. Either with a LabVIEW application on the webservice machine or the racks able to detect one another and demand a selection of which is master and slave.

Thanks again,

Neil.

[Neville D]

QUOTE (NeilA @ Jul 17 2008, 01:53 AM)

Thanks for the response.

My first concern with TestStand is will I have the same problem with the TestStand where each system has to act as well on its own as it does together with a second test system? I am reluctant to suggest we have a seperate master PC with TestStand installed just to asset control the RF Test Systems i.e. I would like my final solution to be deployable as a rack with an embedded PC that can perform measurements on its own or with another rack. Either with a LabVIEW application on the webservice machine or the racks able to detect one another and demand a selection of which is master and slave.

Hi Neil,

I have never used TestStand before, but I suppose you should be able to build exe's out of it, to install on each separate rack system.

You could have a startup app (in TestStand or LV) that queries all the instruments/harnesses available (whether its 1 or more connected racks), and based on this logic, decide what set of tests to expose to the user. Sort of like a *IDN? command in SCPI.

These tests can then be ordered/run through TestStand. Writing a test sequencer (or test executive) is usually a LOT of work, and if you already have TS you should just use that. That decouples the problem of writing the actual test routines from worrying about how to call them, and organize the results etc.

You might get your local NI Rep to come in and explain the capabilities of TestStand

as applicable to your use-case.

Neville.