Agilent OSA Data Acquisition - Where to begin?

[ap8888]

One more post and then I'll wait for your response:

Regarding "Trace Xfer.vi" in the LLB we've been discussing:

1. Do you know the meaning of the "FORM REAL" command? I can't find it in the manual.
2. Do you have an idea of what the output of "TRAC:DATA:Y TRA" is? If so, how do the three VISA Reads retrieve the "sign", "digits", and "bytes" stored in this read data?

Thanks in advance.

[Troy]

Alex,

With regard to the simplified example, I use the constants, which are instrument handle constants, to ensure the shift registers (arrow boxes on either side of the while loop, passes data from output to input on each iteration) on the while loop have data.  You should always try to ensure that the shift registers are wired to some known value, or they may take on the last value that was in them at a previous run time.  The practice of not putting constants on shift registers has caught me and most others that write in LabView at one point or another, and it can be a bit frustrating to track down.  So best practice is to ensure you know at every step of the way that the shift register is loaded with something, even if it's an empty constant.  

They also helps to satisify the LabView rule that every tunnel out of the case structure must have data tied to it in every case.  For the 7th case specifically I didn't want to pass the instrument handle from the input side of the case, because we closed it.

The semi-colons at the beginning of each SCPI command isn't really a requirement, but something I practice to force SCPI back to root, and its a "if it ain't broke don't fix it" kind of thing as well.  You can "concatenate" SCPI commands together in the same level without re-typing the level, but I haven't had much success at this, but I also haven't messed with it that much.  Its just as easy for me to type the full SCPI string as it is.  For an example, if your previous command to the instrument was part of the SYS sub set, and the next command is also part of the SYS subset, technically you don't have to send the SYS part of the command set again.  This is how I understand it is supposed to work, but I am not a SCPI expert.

As for what commands etc I send, I usualy only do what I need.  I very rarely preset the instrument in my code for use here in the office, primarily because the engineers and myself will usually have the instrument setup into the state we want it, and we just use the code for capturing traces, or doing long term tests.  For ATE systems that I send to our factories, I will preset the instrument, because I need it to start from a known state so that I can ensure the setup is correct.  As a general rule of thumb I tend to do only what I need to do when talking to the instrument.  The VISA inherent VIs handle all of the bus initialization via the property node, and general GPIB settings, so it isn't necessary for you to really do much, other than maybe change or establish the timeout as I did in case 1 of my example.  Hope that makes sense.

As for your last post, the FORM REAL is telling the analyzer to format the data into binary data format of either a 32 bit or 64 bit form.  Check page 184 of the programming manual for info there.  They do this for speed, though generally taking traces isn't really all that speed critical, and honestly, I feel it takes more time on the PC side to disect the binary data back to useable numbers.  I prefer to have the analyzer send it as FORM ASC which sends the data back as ASCII strings, which the VISA read directly outputs, the its just parsing a string to get the data you want, and most of the time, you can go directly to an array, as the data usually comes back as a comma separated values.

Finally, the command TRAC:DATA:Y? TRA is covered on page 250 of the programming manual, but when done as a query as I have, will return the Trace A Y axis points.  Also as per the manual, the DATA and Y parts are optional.  The string can be shortened to TRAC? TRA and will produce the same results.  The formating of the data coming back is dictated by the FORM command we discussed before.  They like to use the REAL format which returns the data in 32 or 64 bit blocks, but I prefer to just use the ASCII format, as the conversion at the PC is much simpler and I don't feel there is much of a time benifit in binary (PC memory is cheap as well, so its not as big of a deal to transfer as ASCII as it once was).

Sorry for the long post this time, lots of information on this one though.  Hope that answers all the questions. 

[ap8888]

Thank you again. You've answered most of my questions. Some other questions that I have are:

1. In Trace Xfer.vi, how do the four read functions that are after the "TRAC:DATA:Y? TRA" write function retrieve "Sign", "digits" and "bytes"?
2. Is there anything in Trace Xfer.vi that you see needs improvement (e.g. should it be changed into a state machine format)?
   
3. Also (and perhaps most importantly), how does one modify this VI (Trace Xfer.vi) to continually plot the trace (in "real time") instead of just grabbing a single set of values?

[ap8888]

Also a question on programming:


       4.  I notice that so far the programming in these VIs has been single-lined. In the programming manual, there are examples of large(r) programs. Can I place numerous lines of code into one VISA                 Write function or do I have to go step-by-step? I assume that if you place a large piece of code into one Write function, you'll get a large bulk of data from your Read statement, but perhaps one                 can still split this into coherent discrete data with String functions.

I hope my question is somewhat clear.

[Troy]

The VI determines the "# Sign", "# Digits", and "# Bytes" by reading only 1 byte at a time.  That is what the constant wired to the input side of the VISA Read VI is telling it to do.  If you look at how the format FORM REAL constructs the data response, it starts with "#", then one byte for the number of digits in the byte count which is then sent to the next read to read the number of bytes to be sent back as actual data, which is then sent to the next read to read the actual data bytes.

Since this was fairly quick I did a simplified version of the same thing, using the FORM ASC.  As you can see, its much easier to figure out what is going on.

As for running this "real time", depending on needed sweep times, it is likely that the GPIB bus is just not going to be fast enough to return the data, binary or ASCII, to keep up with the analyzer.  From my experience, Agilent hasn't supported the 488.2HS protocol, so the limiting factor is the bus speed via GPIB.  Serial is slower, and I don't have any equipment yet that supports LAN or USB, so I can't speak to those speeds.  However, this is not something that is normally done this way. 

Are looking for a glitch in the spectrum?

And to answer your most recent question, yes you can include multiple commands in the same string, and even do multiple queries in the same write.  I don't do this much, but I believe they come back as comma separated values, providing you are using FORM ASC (which is normally Agilent's default setting).

[ap8888]

---

As for running this "real time", depending on needed sweep times, it is likely that the GPIB bus is just not going to be fast enough to return the data, binary or ASCII, to keep up with the analyzer.  From my experience, Agilent hasn't supported the 488.2HS protocol, so the limiting factor is the bus speed via GPIB.  Serial is slower, and I don't have any equipment yet that supports LAN or USB, so I can't speak to those speeds.  However, this is not something that is normally done this way. 

Are looking for a glitch in the spectrum?

---

My ultimate goal, as we discussed before, is to create a program that retrieves a trace at a speed that is as fast as possible and then processes it (finds wavelength shifts for the peaks that vary with time). I assume that even with GPIB I can obtain a speed that, although slow, demonstrates my concept.

Let me know what you think about possible implementations of this concept and how one may modify that discussed examples to fit this requirement.

[Troy]

We can do that to a certain degree.  Let me look at a couple of things over the next day or so, and if you can let me know if the example works now, we can see if we can come up with some concepts for you.  In general, we are going to have the PC take full control over the analzyer, controling its sweep, and taking data for analysis, and doing that analysis.  Depending on the number of points per trace, we can run this at a fairly quick pace, but it would be no where near the analyzers full speed if a low sweep time is a result of the settings.

[ap8888]

Hi Troy.

Regarding "Simplfied Example 2.vi":

1. Undefined header –113 error (twice) on screen when “Setting the print format used by the instrument, using function cmd”. Then the rest of the text shows up immediately along with the error dialog. I've attached a screenshot of this hapenning.
   

2. Your version of the "New Trace Xfer.vi" works well. I'll begin studying and modifying it to my needs.
   

As you said, when you are free please let me know if we can come up with some concepts to suit my project requirements. What you said in your last post is exactly what I need.

Thanks again,
Alex

[ap8888]

Hi again.

I wanted to ask another question:

1. You may actually be discussing this when you reply, but I wanted to ask nonetheless: It's easy to place the whole New Trace Xfer program into a while loop, and the refresh rate of the graphs is fairly quick. I understand that a while loop without a time delay will run as fast as the CPU can, and so here, I assume, the bottleneck is the transfer speed of the GPIB connection and not the CPU. How does one optimize the OSA to transfer this data as quick as possible? I read somewhere that turning off the OSA's display is one way, and of course reducing the number of plot points is another. I suppose my question is: Is it true that the three bottlenecks right now are the 1) GPIB connection, 2) the sweep time on the OSA and 3) the overhead memory usage on the OSA, like the display?

Message Edited by ap8888 on 07-02-2008 09:28 AM

Message Edited by ap8888 on 07-02-2008 09:28 AM

[Troy]

Alex,

I wanted to let you know that I saw your posts this morning, but I have had a couple of hot items come up today that must be finished by tomorrow.  I will try to respond with answers to your questions by weeks end.  I just didn't want to leave you hanging.  Sorry for the delay, but gotta do what the boss wants...