Agilent OSA Data Acquisition - Where to begin?

[Troy]

Alex,

Are you seeing the Undefined Header error on the screen of the OSA?  I will review the code and the SCPI commands and see if I see the error.  Also, did you confirm that the GPIB address between the OSA and the application were the same?  Likely they are as we ususally don't get a TO error if we didn't at least get info to the instrument.

I will modify the driver to use the LabView native VISA functions, and I think you will see what I am talking about.  I don't really have anything against the instrument driver per se, but there with this example, there is no real reason for it.  I find with as much instrument control as I do, sometimes I use the drivers (typically ones developed NI), and sometimes I do my own.  Usually when I do my own, the available instrument driver VIs either do too much having other functions or they don't go far enough to get the setup or data I need.  So I typically end up about 70% available drivers, and 30% my own overall.

I have some stuff on my plate this morning, so I will try to get this out this afternoon, or sometime Monday if things fall apart around here today.

[Troy]

Alex,

I was able to make a quick modification to the New Example 2.vi that may fix the GPIB errors.  Looking at the programming manual you sent, and my experience with SCPI, I added a : to the beginning of each command.  The commands themselves looked to be correct, so I am hoping you were getting the unterminated header errors and this will fix it.  Let me know what you find.

[ap8888]

Hi Troy. I tried running the example and had the same problem.

I've attached a screenshot.

[ap8888]

As for the 86140B Trace_Screen Capture.llb example that I mentioned earlier: I'm glad that it at least works to a degree. I can manage to capture an instantaneous image of the OSA screen on the XY graph and even export to an excel file, but the "Screen" button (which Agilent said should save to a GIF) does not work). Agilent told me afterwards that it's because one of the VIs used requires a firmware update, which I am in the process of ordering. If you find another mistake in this VISA-based file, please let me know. It looks promising, I think.

In fact, my major goal is to have a program similar to Trace Screen Capture but is a constantly-updating (that is, a chart instead of a graph) plot which can continously export information about the peaks found on the OSA's screen.


Message Edited by ap8888 on 06-27-2008 11:37 AM

[ap8888]

---

I will modify the driver to use the LabView native VISA functions, and I think you will see what I am talking about.  I don't really have anything against the instrument driver per se, but there with this example, there is no real reason for it.  I find with as much instrument control as I do, sometimes I use the drivers (typically ones developed NI), and sometimes I do my own.  Usually when I do my own, the available instrument driver VIs either do too much having other functions or they don't go far enough to get the setup or data I need.  So I typically end up about 70% available drivers, and 30% my own overall.

I have some stuff on my plate this morning, so I will try to get this out this afternoon, or sometime Monday if things fall apart around here today.

---

Hi Troy. Will you be able to do this tomorrow morning?


Thanks again,
Alex

[Troy]

Sorry this took so long.  Busy day on Friday. 

Attached should be a simplified version of the same example.  Let me know if you have problems with it running.  As you can see, we should be able to accomplish the exact same functionality as we did with the instrument drivers, but we used the native VISA functions within LabView.  If you run this and get the error popup, please let me know what the instrument itself did.  Did it display any error messages on the screen such as unterminated header or query?

As for your final solution let me make sure I understand your goal.  You want to continuously pull marker points from the analyzer and plot them into a strip chart, is that correct?  If so, do the markers need to be repositioned each time or do you place them and just want to watch them for a period of time?

Just an FYI, I have a pretty busy week this week.  I will try my best to keep the communications coming as quickly as possible, but I may get delayed here and there, so please accept my apologies in advance.

[ap8888]

It's okay Troy -- I appreciate any help you can provide.

1) I'll run this example and will let you know if there's any problems running it. However, the OSA is in my lab and I won't be there until Wednesday. In the mean time, I'll see what I can interpret in LabView without the OSA in place.

2) Regarding my final solution: Consider a waveform (amplitude vs. wavelength) on the OSA that has 2 peaks. These peaks represent FBGs on an optical fiber and will experience a shift in time. My real goal is to able to continously pull/calculate 2 shift values (call them shift1 and shift2) that vary with time. Now the OSA, from what I understands, allows one to place a marker on a peak, but when the peak moves, the marker (from what I remember) does not stay on the peak. In order to achieve my goal, it seems, I would have to do one of the following:

1. Somehow force 2 markers to stay on the 2 peaks and pull their 'wavelength' values to LabView continously.
   
2. Pull the entire waveform continously, plot it within labview, and calculate the 2 peaks in time within LabView.
   

Let me know what you think.

By the way, if there's a time that I should expect responses from you (maybe you're more available in the evening or the morning), please inform me. Otherwise, I'll just try to respond ASAP.

Alex

[Troy]

Your second option is going to be what you are going to use most likely.  I am not sure if the OSA has the ability to peak track, but even if it does, if it works like I have seen on our RF spec ans its not the best, and it cannot track multiple peaks.  So yes, best thing to do is pull the trace via GPIB, then write some analysis to find the two peaks.   

I was looking at the Agilent trace capture LLB that you sent, and you can likely use the VIs in it, specifically the trace plot.  Dont use the HCOPY version as that will just generate a useless GIF of the screen, and it takes 30 seconds or so to do that.  You just want the formated trace data.

I don't really have any specific times I am available, but ususally I am more active here in the evenings.  Since it will be a couple of days for you to get to the equipment I think things will work out just fine.

[ap8888]

Perhaps we can do work in parallel; I'll let you know how your example goes with my hardware in a few days, while in the meantime, we focus on "Trace Xfer.vi".

Are you suggesting that the "Trace Xfer.vi" that is called in frame 0 of the case structure in the main VI is a good candidate for my intended application? Is there anything in Trace Xfer.vi that you see needs improvement? Also (and perhaps most importantly), how does one modify this VI to continually plot the trace instead of just grabbing a single set of values?

Excuse the simplicity of my questions -- I'm sure you understand.

Thanks,
Alex

(By the way, what does "Xfer" mean?)


Message Edited by ap8888 on 06-30-2008 05:47 PM

[ap8888]

I've looked over the "Simplified Example" VI you created and have a few questions:

1. On the 1st and 7th case you created constants for the instrument handle and error tunnels (appearing as I/O in purple and a cluster). Why must I do this?
2. Why do you place ":;" before your commands? I couldn't find this requirement explicitly in the programming manual.
   
3. From your own work, which commands do you usually execute before you start calling out individual cases? I assume that I should always try to ensure that my connection is live, perhaps by doing an ID query. Then should I reset? Or is all this unnecessary if I am already using the VISA  Open function? Does it alone take care of all the initialization? Can I begin to do my work right after VISA Open and before VISA Close?

Thanks again for the example; I understood it nearly in its entirety!

Thanks,
Alex