How to check when niFgen_SendSoftwareTrigger finished

[michael_b]

Hello all,

I am using PXI-5421 awg and I want to step through a sequence using the BURST trigger mode in combination with calls to SendSoftwareTrigger.
Now I found out when I make two subsequent calls to SendSoftwareTrigger the second one has no effect, if there is no pause between them (_sleep(100) or something like that.). But I need to be 100% sure that the awg has switched to the next waveform in the sequence, because I don't know of any method to find out which waveform in a sequence is currently beeing generated.

Thanks is advance,
Michael

[Andre_Saller]

I tried to send two software-trigger immediatley one after another, without any delay, and it worked. I used an example in LabView(nifgen_Arb_Sequence_Example.vi), because there was none for C. Do you have the latest driver? Maybe it is some other configuration-issue. You could check the LabView-Example, and compare the settings therein with your settings.

[NeilF]

Unfortunately, there is currently no way to know when a software trigger has been acted upon except indirectly.

When you are in sequence mode with burst triggering, the current waveform plays repeatedly until a trigger is received, which causes the signal generator to advance to the next waveform in the sequence. However, after the trigger is received, the current waveform plays to completion first. So if you have a 1000 point waveform, and the trigger is received while you are halfway through the waveform, the remaining 500 points will be generated before switching to the next waveform. If you send another trigger during that period of time, it will be ignored (it is redundant).

In a future release of NI-FGEN (sorry, I can't promise any date), we will add some features that will allow you to jump out of a waveform immediately, without playing to completion. This could be beneficial in your case. However, there will be some minimum amount of time that you need to wait before sending yet another trigger and jumping to the third waveform. It will be relatively short, but still, the data for the third waveform needs to be fetched from onobard memory into a cache for outputting.

The easiest workaround is to put a software delay after you call Send_Software_Trigger equal to the amount of time it takes to play the waveform once. Just take your number of points (1000 for example) divided by your sample rate (100 MS/sec for example) to get the time (10 us in this example) that you need to wait before sending another trigger. I suspect you are running much slower than that to be experiencing this issue.

Why do you need to assert software triggers so closely together? What is the minimum time you are looking for? Do you need to switch between waveforms very quickly?

Neil F.
Software Engineer
Modular Instruments R&D
National Instruments

[psisterhen]

The problem that michael_b is seeing is probably not a configuration issue or a factor of the driver version (although one should always get the newest driver version, if possible).

In Burst Trigger mode, the 5421 loops on a waveform until a trigger is received, and then it moves to the next stage in the sequence. However, the device will finish generating the waveform before jumping to the next stage. For example, if the device is looping on a 1000 sample waveform, and gets a trigger when it is on sample 10, it will generate the remaining 990 samples, then go to the next waveform. If another trigger comes in after the first trigger, but before the device moves to the next stage, it will be ignored. That is what michael_b is seeing.

There is currently no simple way to determine exactly what stage the device is on. But I can suggest a couple of solutions:

1) Put a marker (an output trigger) on the first sample of each stage. If you have another digital input device in the system, it can watch that line, and notify software whenever the 5421 outputs a marker (meaning, it has just moved to the next stage).

2) If you know how big each waveform in the sequence is, you can figure out the maximum time to wait between sending software triggers. Since the worst case scenario is when a trigger is received on the first sample of a new loop (and the device will generate the entire waveform before moving on), you never have to wait longer than it will take to generate the entire waveform. If you have a 1000 sample waveform, with an update rate of 10 MS/s, you don't have to wait longer than .1 ms. If you wait that long, it might be slightly more than necessary, but that is the upper bound.