Search code examples
automated-testsethernetlabviewremote-controlgpib

How to control EM Test Equipment remotely?


I am trying to control EM Test Equipment (AutoWave, PFM200, VDS200Q) remotely.

I have received LabVIEW and C# driver for that from the manufacturer and I have also read the manual. As I have never done similar work and automatic tests before, can someone tell me from where should I start? Do I have to develop the framework for that?

My main aims are as follows,

  1. Use the segment files (.dsg) generated/exported from Autowave.control software link
  2. Execution of .dsg files
  3. Test result evaluation and reporting after every single .dsg file execution

The picture below shows the test environment of the EM Test System. The main communication protocol used here is Ethernet and GPIB(IEEE 488).

EM Test Envirenment

Any help would be appreciated. Thank you!

Tom


Solution

  • It's impossible to give you a precise answer without knowing more detail about your requirements and your knowledge, and I'm not familiar with this specific field of electromagnetic compatibility testing, but if you are already capable of working with LabVIEW, and the manufacturer of the instruments supplies a LabVIEW driver which can do the operations you describe, then with enough time and effort you should be able to achieve what you want. A lot depends on how this will be used: is it just a tool that you will use, or must it be shared with other users who will expect it to look and behave like commercial software?

    There are two ways you could think about the problem:

    Top-down

    Write down or draw a picture of the overall test process. Probably you need to collect some information from the user, then configure the hardware, then set some conditions and make some measurements, then possibly change the conditions and make more measurements some number of times, then return the hardware to its original state and end communication, and finally analyse and report the data you collected. Design the user interface and the high-level program structure to do that. Then start implementing the actual instrument communication and data handling for each step. For the steps you haven't implemented yet, you can make placeholder code that e.g. just asks the user to confirm that the operation has been done manually.

    Bottom-up

    Think about the operations you actually need to do with the hardware: what are the inputs, what messages are sent or received, what are the outputs. Implement one of these operations as a module (LabVIEW VI) that you can re-use. Probably your data can be divided into configuration for the whole test and settings for individual test steps, so think how best to store that data and pass it around. Build more modules and link them together to cover more and more of the required functionality.

    In practice, I would do both of these: start low-level to understand how the driver really works and what the data is, but at the same time work on a concept of how the final product will behave and be structured.

    I strongly recommend looking at the templates and examples that come with LabVIEW, such as the Simple State Machine and Finite Measurement examples. Using these as a starting point can save you a lot of effort, but if you find them hard to understand maybe you need to build your skills a bit more before taking on this project.

    Finally, if this needs to be highly professional or you have a deadline to build it, perhaps you should look at a test executive application such as NI TestStand instead, or if you are working with automotive systems possibly ECU-TEST? Both of those can interface to LabVIEW. You may even have access to TestStand already if you have one of the NI 'suite' licences, or be able to add it for a reduced price.