Confusing triggering behavior on MSO

[AllisonAFM]

Hi folks,

I'm seeing some confusing triggering behavior on the MSO and I'm hoping someone can help me understand what is going on. 

I have my FGEN output T'ed off and going into both oscilloscope inputs. In the VirtualBench stand-alone application, I set the FGEN to outupt a 1 Hz sine wave. Then I run the attached vi, which is just data collection. When I ask it to collect data from the same channel as it is triggering from, it triggers once per second, which is what I expect. When I ask it to collect data from channel 1 and trigger off of channel 2, or vice versa, it triggers as fast as I'm letting the while loop run. This can be seen by the trigger time stamp and also the graph updating. This is not what I expect, since I wouldn't expect the choice of data channel to affect the triggering. 

Also, notice that I set the pretrigger time to 2 ms, but it is 4 us when I query it. I'm not sure what is changing this value. This may or may not be related, but it happens in whatever the data collection/trigger configuration.

thoughts?

-Allison

[bstreiff · Accepted solution]

You don't set sample rate or acquisition time. If you want those to be preserved from the settings you made in the VirtualBench application, you should set "Reset" to "false" on MSO Initialize VI. Otherwise, they get set to default values. The default values for sample rate and acquisition time are 250MHz and 4 us, respectively. You set a pretrigger time of 2 ms, which far exceeds the acquisition time, so it gets coerced down to 3.992 us (which is the largest value for pretrigger we can use with a 4 us acquisition time at that sample rate).

As far as the triggering itself is concerned, in the VirtualBench API you must enable the channel that you want to use as a trigger. If you configure a non-enabled analog channel as a trigger, your trigger type gets coerced to an Immediate trigger (you can see this with the MSO Query Trigger Type VI). This was by design, although I do agree, in this particular case it does seem counterintuitive.

The solution would be to enable both channels, but then only graph the channel that you are interested in (you can use the Index Array primitive on the waveform in order to pick out individual channels).

[AllisonAFM]

Hi Brandon,

Thank you, my larger program is working beautifully now. I was trying to debug using "trigger reason" on the read vi, which gave a reason of "normal."

The pretrigger thing turned out to be a red herring, but I appreciate you taking the time to explain it.

-Allison