Agilent ENA E5062A Trigger Questions

[Becky77]

We are using Labview 8.2 to control an Agilent ENA E 5062A via LAN crossover cable.  We would like to gather a frequency sweep of data at 10 sweeps per second for a total of 2-3 minutes before auto-saving the data to an Excel worksheet.  We have downloaded and installed the correct instrument driver.  We have also validated our connectivity with the instrument via NI-MAX and Agilent Connection Expert.

We looked at a Sample VI that came with the instrument driver.  Based on this we have set-up a block diagram that begins with an Initialize Sub-VI, then goes to a Configure Trigger Sub-VI, followed by a Send Trigger Sub-VI.  The Initialization Sub-VI runs, but the Configure Trigger Sub-VI gives an error of "Undefined Header" in both the Sub-VI front panel and on the instrument.  The Send Trigger Sub-VI gives an error of "Trigger Ignored" on the Sub-VI front panel and on the instrument. 

We also tried testing the Trigger functionality in the Open VISA Test Panel in NI-MAX.  We go to the Basic IO Tab and the VI Assert Trigger Tab and click Execute.  This gives the same error of "Trigger Ignored" on the network analyzer, but returns no error into the NI MAX software.

We developed this VI to meet our above goal of 10 sweeps/second for 2-3minutes.  Our thought process was to trigger a sweep, save the data to memory and loop for 2-3  minutes before saving the entire data set to excel.  However we are open to any other ideas about the best way to reach this goal.  If needed we can post the VI or NI-Spy results.

Thank you in advance for any help you can offer!  

[NathanT]

Hello Becky,

      First please confirm that you are using the project-style instrument driver.  Second, do the all of example VIs run correctly without any changes to them?  Third, are you using the most current firmware for your instrument?

It sounds like you have done a good job isolating the problem down to a couple of VIs, but just make sure that there are not any extra VIs in the example that you post.  Also please take an NI-Spy capture of the problem occuring, save it as a .spy file, and post it to this thread.

      For your general architecture, I think that a producer/consumer design would work quite well.

Cheers,

NathanT

[Becky77]

Nathan,

Thank you so much for your help thus far.

It makes the most sense to answer your questions before delving any deeper.  We have confirmed that we do indeed have a project-style driver.  In addition most of the example VI’s run independently. (For example, we now have the Trigger working properly, but not the Configure Trigger VI)  In addition we updated the firmware on our Network Analyzer to the latest version. 

We have spent much of the rest of our time trying to create a producer/consumer design as you suggested.  However we are uncertain of the best method to use this technique to achieve our goal.  Ultimately we would like to trigger a sweep, read out the data, transfer to a queue and loop for a few minutes as fast as possible, while simultaneously the queue is directed to a consumer loop and written to a file (preferably something that can be opened in Excel).  We have attached our first attempt at a VI to achieve this goal.  In summary: 

In our Producer Loop we:
1) Configure the Trigger (still does not function with the instrument)
2) Trigger the Instrument (now does work)
3) Read the Data from the Instrument
4)  Enqueue the data

In our Consumer Loop we:

1) Dequeue the data

2) Read the Stimulus Array

3) Cluster the Stimulus Array with our Dequeued Array

4) Write this Cluster to a .TDMS file

We are new to programming in Labview so any and all suggestions are appreciated. Thank you again for any help you can provide!

Becky

[NathanT]

Hello Becky,

       I am glad to see that you are making progress.  Thank you for confirming that you are using the project-style instrument driver.  My specialty is instrument drivers, so I would like to find out what is causing the Configure Trigger to not work properly.  Please isolate the code down to the minimum amount that reproduces the problem, and then take an NI-Spy capture of the problem occuring.  With that .spy file, I can see if commands are being sent incorrectly.

As far as the producer/consumer pattern goes, you should only be doing instrument I/O in the Producer Loop.  The benefit of the design pattern is that you can decouple the instrument I/O from the file I/O.

A couple of other suggestions:

- You don't need to explicitly call the Error Query VI since it is being called by the high-level VIs in the Instrument Driver

- You should make your queue data type the same datatype as the thing that you will be putting into it

- You should probably choose a number of elements for your queue

- You should call the Close VI for the instrument driver at the end of the application

Cheers,

NathanT

[Becky77]

Nathan,

Thank you again for your response.  We have come a long way since the last post and are now able to successfully Trigger the system to sweep and loop.  I believe we modified all of your suggestions from the last post in addition to making some modifications on our own.  We figured out how to prevent the Initialization from resetting the Network Analyzer and were therefore able to remove many of the I/O commands that were causing us problems, including the Configure Trigger. 

A quick synopsis of our layout (in the attached VI) is first we do a Read Stimulus Array, followed by a While Loop (Producer), in which we Trigger a Sweep, Read the Data and Enqueue the Data.  We would like this first While Loop to happen as fast as possible (10 sweeps/second).  Then the next While Loop (Consumer) checks the Queue Status, Dequeues the data, Combines it with the Stimulus Array and Writes to a Measurement File. 

The program executes and we do not get any errors. However the problem that we run into is that we do not appear to have any data in the Queue and only header data is saved into the worksheet in the Write File output. 

We believe that we have the right data type into the Obtain Queue, but there may be an issue with this parameter. 

Any and all suggestions are appreciated.  Thank you again for all of your time.  We have definitely learned a lot and feel we are close to a fully functioning VI!

For your reference we have also attached an NI Spy File.

Take care,

Becky

[Becky77]

Also, here is an NI Spy Capture of our VI.

Thanks!

[NathanT]

Hello Becky,

       I am glad to hear that you are making so much progress and that the instrument driver is working like it should.  It is very important to test the individual parts of your application and then put them all together and see if they continue to function how you expect.  Since it seems like you are getting the data that you expect from the instrument through the instrument driver, I recommend that you test your queue next.  I made a couple of changes to your VI as an example:

1.  determine the array size that you will need for each reading, and then pre-allocate an array to serve as the queue element.

2.  Set a limit on the queue size.  I just used 2000 as an example, you will need to determine the maximum number of elements that you will need.

3.  Add an array to display the instrument data that has been passed through the queue.  I only used the Build Array as a temporary testing measure.  For better performance, you should pre-allocate your array and then replace elements in it.

I also took out the Write to Measurement File Express VI so that you can test without it for now.  Once you are certain that all of the correct data is getting through the queue, then I recommend that you use non-Express VIs to do file I/O.  I disconnected the Stimulus Data from the consumer loop.  Why were you appending it to all of the data that was being written?

To see how fast the data aquisition while loop can run, just try running it without the queue and consumer loop.  The main bottle neck will be the instrument or communication with the instrument.  This will give you a good baseline on what performance goals you can have for the application.

Cheers,

NathanT

[Becky77]

Nathan,

We are happy to report that our VI is now fully functional.  Following your post, we looked at each individual part of our VI again and realized that one of our main problems was actually the output from the “Get Data and Memory Array” subVI for our network analyzer.  When the wire out of this subVI was probed, we found out that it was not outputting an array, but rather a non-recognizable signal because the output type had been set to Real 32 instead of ASCII.  After we made this change, we saw an immediate solution to our problem.

In order to gain the highest speed possible, we tried running the instrument calls with and without the loops, and we learned that we do not loose significant speed with the queue and loops.  Thus, we have kept them in, along with our call of stimulus data (as we are coupling the frequency and magnitude data for each sweep in order to locate a dip in magnitude at a particular frequency).  Thank you for all of your assistance!

Becky

[NathanT]

Hello Becky,

       I am happy to hear that your VI is fully functional now after sucessful troubleshooting on your part.  I wish you the best of luck with your tests.

Cheers,

NathanT