Waiting for Trigger on Oscilloscope

[Varekai]

Hello,

I'm having some trouble trying to figure out how to get a VI to wait for an oscilloscope trigger.  I'm using a TDS5054 and I would like to acquire a power on reset pulse from the scope.  I have tried modifying the examples that came with the Labview drivers as well as using VISA events.  The VISA events didn't work because the Trigger event isn't supported by this scope according to Labview.  I know there has to be a way to do this, but I'm pretty stumped.  Any advice would be greatly appreciated.

Thanks!

- John

[Dennis_Knutson]

For GPIB, the only NI-VISA trigger event is a trigger generated by the controller, I believe. That's quite a bit different than what you want to do. Can you explain a bit more about your scope setup and the signal you are trying to capture? Like, what is the source of the trigger? Is it the pulse itself (i.e. Ch 1)? How have you set the trigger level and slope? I don't have the driver for the scope handy but have you tried to configure the scope manually? You should be able to do this and once you have, doing it from LabVIEW is usually just a matter of repeating the steps.

[Varekai]

Thanks for the response Dennis.

My setup consists of a CompactDAQ unit with a NI 9263 module acting as the power supply for a test board.  I have the power on reset pin from this board hooked up to Channel 3 on the oscope and the power supply attached to Channel 2.  The way I trigger the Oscope currently (by hand) is by setting the level of Channel 3 to about 4.5V (the POR is a ttl signal).  Once the scope is triggered, I change the time window so I can see when the board powers up and how long it takes for the POR to occur.  This works fine manually but  I would like to have LabView do this entire process as I have to do this many times over various conditions.

So I guess the question becomes, does the oscope send out some kind of signal that says it has triggered?  Or do I have to keep reading the waveforms until it detects a change?  Also if I try the second approach (if it's valid), how will this effect the windowing on the scope (and Labview) and will I be able to see the board power up and the time in between?  I would like to think there is some kind of signal or status bit I can check with a VI so I can just have my VI wait until it triggers to acquires the waveform.  That method seems to make more sense if it's possible.

Thanks for the help.

- John

[Dennis_Knutson]

The edge triggered example does some things that you might need to modify. The channel select and the trigger source are probably okay but the Read function might be doing too much. What it does is initiate the scope and then does a OPC? (operation complete) query. When the instrument returns that the operation is complete, a Fetch Waveform is done. You might want to do the initiate, turn on the power supply, and then run the Wait for Operation Complete function. To get channel 2, add another configure channel function and do another Fetch Waveform for channel 2 after you've got channel 3.

[Varekai]

Ok I have almost exactly what I want.  I'm just having some trouble with the acquisition.  I created the attached VI and it sets up the scope as I want it for the trigger but when I try to read the delay between the two channels, LabView returns this error:

Error -1074000000 occurred at tkdpo7k Error Query.vi
Possible reason(s):

Instrument reports:
402,"Operation complete"
2225,"Measurement error, No waveform to measure"
0,"No events to report - queue empty"

Complete call chain:
     tkdpo7k Error Query.vi
     tkdpo7k Fetch Waveform Measurement (Time).vi
     tkdpo7k Read Waveform Measurement (Time).vi
     Untitled 2

All the VI does is configure the A to B sequence trigger, then calls a test VI which simply creates to voltages out of a DAQ to simulate the power on reset.  This works fine and the waveforms appear perfectly on the scope itself.  The problem comes in when I try to do read in a time delay measurement after the trigger.  I then get the above error.  Any advice?

Thanks.

- John

[Varekai]

Ok new update.  I am able to acquire the waveform data using the driver's Read Multiple Waveforms vi.  So I can get the waveform data into Labview.  For some reason I had to use 2 reference channels and store the data there first, but it got rid of the error I mentioned above.

Unfortunately I still can do the delay measurement I want and it gives me a new error.

Error -1074000000 occurred at tkdpo7k Error Query.vi

Instrument reports:
402,"Operation complete"
2215,"Measurement error, No crossing, second waveform"
0,"No events to report - queue empty"

Complete call chain:
     tkdpo7k Error Query.vi
     tkdpo7k Fetch Waveform Measurement (Time).vi
     tkdpo7k Read Waveform Measurement (Time).vi
     A_to_B_Sequence_Trigger_Test.vi

This one I am stumped by.  The second waveform clearly crosses the 50% mark and the graph I get in LabView from the Read Multiple Channels even shows it!  Here is an updated VI with the changes.  Any advice would be great!

Thanks

-John

Message Edited by Varekai on 10-26-2007 02:47 PM

[Dennis_Knutson]

Sorry, I don't have the scope to run the VI so I don't know why the instrument might be reporting the error. Since you have the data in LabVIEW, you can use functions there to calculate the delay. One way would be to use a couple of Basic Trigger Level Detection functions on each channel. Use the Index Array function on the waveform data for this. There's an input of the Basic Trigger Level Detection called location mode. Set to time and then you can just subtract the two values.

I don't know if this will be more accurate or faster than the scope doing it. You might want to contact Tek support to discuss the measurement issue.

[Varekai]

Yeah I had a feeling I'd either have to contact Tek or do it in Labview so I started doing the math on the waveform data just in case the VI wouldn't work out for me.  I think that should be accurate enough for what we are doing but if the engineer I'm doing this for says otherwise I guess I'll have to have a chat with Tek.  Thanks for your help Dennis!

- John