agilent 86100a acquire waveform into labview

[saqib_zahir]

Hello world,

I have a simple question. How do I capture the same waveform I can see on my 'Agilent 86100A' oscilloscope into labview?

My attempts:

Have tried using the instrument drivers. The VI I use is 'Agilent 86100 Series Tranfer Current Waveform.vi'.

I can succesfully view a signal but this is incorrect as I expect something else. i.e. my oscilloscpe waveform and the - however this is not what I can see on my oscilloscope. e.g. my signals on my oscilloscope and the one in labview are not the same!

I tried using other example VIs like GPIB-VISA.vi, which works well with my instrument. i.e. I can send commands to save, autoscale the waveforms from labview to control it on my oscilloscope. But Is there a command to retreive the waveforms??? I used http://cp.literature.agilent.com/litweb/pdf/86100-90131.pdf to set the commands.

Any help is appreciated.

Saqib

[crossrulz]

Just saying the waveform is "not what you expected" does not help us.  Show us what you are getting and what you expect.  It sounds like you are getting waveforms from the scope though.

Is the scope constantly acquiring?

Are you getting the right channel's data?

[Alex.T]

Hey Saqib,

I had some thoughts after our support session yesterday that might give us a bit of a better idea as to what is going on.

• Try using an 'Array Size' function to determine the number of points acquired from the device. Then reference that to the example code or device datasheet (See if there are any constants or controls used that possess an equivalent size) and then increase that. What we saw yesterday seemed to me that we were only looking at a small portion of the whole waveform you saw on screen, so we could try increasing the size of the overall data transmitted over GPIB to grab a better representation of the require waveforms. In the device datasheet, you can see certain commands that can be used to increase the buffer size. I think it was points?
• We were seeing a lot of custom built timeout operations in the 86100A driver code. Conventionally with NI-VISA, there are pre-built timeout functions as part of the driver layer that should have cropped up if an actual timeout event had occurred on the GPIB line. We didn't see any of these native timeouts, which seems to me like the I/O between LabVIEW and the device has been successfully communicating, but maybe the instructions themselves aren't implemented correctly.

I also found it interesting that we could repeatedly use the single acquisition VI without seeing any errors, but the continuous acquisition VI would throw some. Try checking for the differences in their implementation.

With regards to the application itself, I think that you should read into how you can trigger and send interrupts along the GPIB line because GPIB itself is a slow communication protocol. It'd be much more reliable to configure interrupts so that you only grab data from the slave device when you've got data you're interested in.

Kind Regards,

[Alex.T]

---

@crossrulz wrote:

Just saying the waveform is "not what you expected" does not help us.  Show us what you are getting and what you expect.  It sounds like you are getting waveforms from the scope though.

Is the scope constantly acquiring?

Are you getting the right channel's data?

---

Hey crossrulz,

There's an 81600A oscilloscope in the lab that's getting interacted with via LabVIEW and the equivalent IDNet drivers. Occasionally, the VI throws custom built errors based on timers and there are some instructions that don't seem to get recognised by the device/implemented properly. Some of the VIs do work correctly but only a small set of samples are received, although on screen we can see full waveforms; this is probably due to the difference between data that's set up to be transmitted over GPIB and data which is used to update the screen. In terms of the data received, I think it looks okay, we're just seeing small regions of noise where nothing interesting is happening. That's why I think we need to increase the number of samples acquired to get the bigger picture; excuse the horrible pun.

Kind Regards,

[saqib_zahir]

Guys much appreciated for your efforts!

I would like to tell you all that your right Alex, it was a sample problem!

Do you know the VISA-GPIB vi which worked flawlessly?

Well, we managed to find an appropriate command - :WAVeform:DATA?

"The query outputs waveform data to the computer over the GPIB

interface. The data is copied from a waveform memory, function,

channel buffer, or histogram previously specified with the

WAVeform:SOURce command. The returned data is described by

the waveform preamble."

So we selected the source as channel 1, by looking @ the waveform source and changing it to the channel 1.

Hence, using the above vi with this command, we we got our signal!

However, it took us a while to find out that the number of samples labview was using was only 97 as opposed to the original signal which had 1350 datapoints!

So the problem was: How do we increase the number of data points?

Looking into the code of the above vi, the number of bytes was 1024. I then entered, 10240 bytes, thinking we would therefore have 970 data points and get closer to our signal received. This is exactly what happend i.e. we exported the data into excel and compared what we expected to what we got and it was very very similar! However the number of datapoints taken were less about 900 ish.

I know we could have used the other code you helped us out with, but to be honest that was beyond us. So many VIs with sub Vis, it was way to difficult. However this simple GPIB-VISA works very well, and is much simpler.

Questions:

a) The data we have is gving us amplitude. However, we are missing the most important data - the time! How do I tweek the code to get the time information along with the amplitude?

b) We are going to utilise all four channels simulataneously into Labview! How do you suggest we go about it? Simply copying and past four times seems as a crude approach but maybe there is a better way of doing it.

c) This vi only works if I hit play with the command entered and in response it spits out data and stops. I would think putting an infinate while loop around the code will give me continous data. However, do you think I should also do this even with 4 channels being utilsed by the labview?

Regards

[saqib_zahir]

I realised my post had more emotions than realised all over the place

saqib

[Alex.T]

Man... that last comment really made me laugh.

That's great news. I'm glad to hear everything's all sorted.

1. There may be a command to retrieve what the sample rate is in the device. You could use the reciprocal of this value for the delta t parameter that's used when the waveform gets built in the acquisition VI.
2. In the code there was an array of channel names; you could use this array to Auto-Index a For Loop and place the acquisition inside.
3. Instead of making the while loop infinite, you could use a Stop Button so that the user can stop the VI gracefully so the hardware is stopped properly. You could also ensure that the loop stops based on an error condition as well, by performing a Logical OR between the Status flag of the error wire and the Stop Button; this is a pretty common technique that you'll find in a lot of VIs.

[G_wang]

Hello,

I have the same problem, did you find the way using GPIB read? How to read it via GPIB read vi? also the VISA - GPIB vi is a group of vi or a single one?

Thanks very much.

G. Wang

[jianxiaozi]

I would like to ask if you have solved this problem, I had the same problem when using the example