synchronizing multiple generators using tclk and script triggers

[TimmTheEnchanter]

Ah--this makes sense!  I do believe that by enabling this property, you are overwriting old data with new data.  Since you are reading in new data, you're seeing the trigger advances on your scope regardless of how fast you read back the data.  So in this case, it shouldn't matter if you are creating a backlog--the backlog is being overwritten.  This is my current understanding.

A common method for letting an NI scope run continuously is to configure the acquisition for a software reference trigger with a lot of pretrigger samples, and never send the software trigger.  While the reference trigger is being accumulated, you can read from where the memory pointer currently is to fetch your data.  This example is called niScope EX Fetch Forever.

The caveat is that you can't set up two different kinds of triggers.  If you aren't able to fetch from your scope memory quickly enough in the loop containing the Fetch VI, then you may want to enable the "Records > Memory" property to overwrite old samples again.  I'd recommend trying this example VI first.

On the note of "loop not running fast enough" I'm just now realizing that Wait Until Next ms Multiple VI has persisted throughout all your attached code in the upper-left corner.  Is there a reason you are slowing down your loop so dramatically with that VI?

Other general things I've noticed about your VI:

1. The sequence structure you're employing is not really enforcing any order of execution that isn't already enforced by the data flow wiring between your VIs.

2. You may want to try to put some your configurations into subVIs to make the code easier to walk through.

[gregoryng]

Thanks for the suggestion about continous acquisition.  I see that this would be good for grabbing all samples forever.  I should have been more precise in saying that I want continually triggered acquisition.  I'm recording continually, but over maybe a 25% duty cycle, and I want the start of acquisition aligned with an external trigger signal.  And I would like to conserve CPU/bus bandwidth because I think that may end up being an issue at the 2 channel 50 MHz samplerate.

Regarding the wait in the loops, they're mostly there because this demo is run at human click speed, so it seemed wasteful for it to busy loop without waiting.  But that is a good observation because in the full-speed digitally triggered application, I would not want to wait in the acquisition loop, and I missed that. But I did in the triggering+monitoring loop (which would just be monitoring), it would remain, beause I only meant to check the status of acquisition every so often, and would not want to waste cycles on this.

Regarding the sequence structure -- it's purely cosmetic and preserved the three stages of the VI (init, run, shutdown) even after I run auto-cleanup.  Certainly I will create configuration subvis along these lines as I move forward as well.

[TimmTheEnchanter]

Hi Gregoryng,

If you want the triggers to both cause a scope fetch acquisition to occur, and to change the output of your arb, then I assume you are not interested in anything that happens after that first acquisition and your trigger arrives?

For example, let me try to draw this out to see if I understand.  If your waveform is represented by "\/", then this is your waveform:

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

|||

Where the vertical lines indicate triggers (and I'm ignoring the fact that the triggers actually change the shape of the waveform).  If I understand correctly, you only want to a subset of what's happening every time the trigger arrives.  Let's say you want to capture "\/\/" (two waveform periods) each time you send the trigger.  That means you'd only receive data from your scope for lthe following parts of the waveform that are in quotation marks ("VV"):

"\/\/"\/"\/\/"\/\/\/\/\/\/"\/\/"\/\/\/\

 |   |       |

Does this sound right, or am I missing your intent?  (If this is too confusing, I'll try drawing out a picture in paint to clarify.)  My understanding is that this will happen automatically, as per "homogeneous triggers" that NI-TClk uses by default.  That's partly why TClk is fancy--it accounts for delays in different kinds of triggers and sets all the referenced sessions automatically.  You can see the first paragraph under "Homogeneous Triggers" in this Help file for more info:

NI-TClk Homogeneous and Heterogeneous Triggers

Also, general info (They have much better pictures here.)

National Instruments T-Clock Technology for Timing and Synchronization of Modular Instruments

-Andrew

[gregoryng]

Yes I think we're on the same page. "Two" periods, then ignore everything until the next trigger.  The demo is very representative of that -- it does that exactly. 

What I was trying to ask earlier was probably just a question about the interpretation of the parameter Number of Records in that init VI. The documentation of the "number of records" parameter appears to only be interpretable in a way that causes the acquisition session to work for a finite number of acquisitions (in my case, received software triggers).  I would like the acquisition session to exist for an infinite number of triggers, or until I abort the acquisition session.  I have been approximating "infinite" with a very large finite number. 

So the question is whether there is a value for that parameter that exactly encodes "infinite" (such as 0 or -1) instead of approximating infinite.  If not, then I assume that there is an engineering/API design reason why it does not exist, and I'd be interested to know why that is.  If it's an oversight, it would be a useful feature enhancement.