Consecutive analog triggering of Analog input and Counter output task

[Migeh]

Hi everybody,

I need to repeatedly generate (and monitor) a fixed pulse sequence for camera triggering.
The generation needs to follow the movement of an objective translator: as the instruments oscillates, its feedback sensor returns an analog sine signal, which should trigger the pulse generation/monitoring.

The issue of how to set the start trigger has already being solved in this post: Kevin_Price gave me a useful tip, suggesting to use an analog start trigger on the monitoring AI, and then use the internal signal “Dev1/ai/StartTrigger” as a digital trigger for the CO pulse generator.

To avoid adding complexity to the triggering scheme, I decided to use a single start signal to generate the full train of pulses for the entire acquisition procedure, monitoring only the first instants of the process to get a general idea of the synchronization.

As you might have guessed, such a method works only for less then a few hundreds (oscillation) cycles, beyond which the small timing mismatches compound to visible levels.

I then had to change the strategy to a generation/monitoring triggered at the beginning of each cycle.

I’m facing two problems now:

1) the AI task, which should be triggered after each positive peak and should last less than a cycle, actually acquires two cycles instead of one,

2) the CO task generates two consecutive pulse trains, as well.

For a specific separation between the pulses, I can find set delays and waveform sizes to values that would allow me to trigger the pulse generation once every two cycles, but this is not a solution.

What should I do here?

Is there a better way to wire the triggers for this specific purpose?

Am I hitting a limit in the speed of the DAQ card?

Would using timed loops (or asking the AI/CO tasks to cover two or more cycles) help?

The VI is really messy, requires several subVIs and contains many parts that are not related to the issue, so I've taken screenshots of the relevant parts and combined them together in a .ppt presentation. If you will need to experiment on the actual thing, I can send you the full project (I'm still preparing the README file).

As for the details of the system:

I use a PCIe-6363 with Labview 2017,

• The AO task has only one channel
• The AI task has four channels, the analog trigger is set on the first channel. Channel 1 and 2 monitor the output and input of the objective translator, while the 3rd and 4th channels read from the camera trigger and from its digital auxiliary output.
• The CO task has implicit timing and defines the pulses by high and low time.

The sample rate for the analog tasks is 2000S/s, and I'd prefer not to change it too much, given that usually the waveforms I generate have periods between 40 ms and 1 s.

If I'm missing some important detail, I'll be happy to add them.

Thank you

--- EDIT ---

I forgot to specify that:

• the AO task runs continuously and uses a while loop only to check when to stop,
• the AI Read VI is repeatedly called at each iteration of a while loop, which stops after being notified by the CO task loop.
• The CO writing task is run at each iteration of a FOR loop, and while it runs, there is a while loop waiting for the task to be done.

AI task is retriggerable

[Migeh]

I forgot to specify that:

• the AO task runs continuously and uses a while loop only to check when to stop,
• the AI Read VI is repeatedly called at each iteration of a while loop, which stops after being notified by the CO task loop.
• The CO writing task is run at each iteration of a FOR loop, and while it runs, there is a while loop waiting for the task to be done.

AI task is retriggerable

CO task is retriggerable and allows regeneration

[Kevin_Price]

Normally I'd advocate to post actual code.  But I'll also admit upfront that I personally *rarely* download and dig into large projects that people post.  That's just a time management strategy on my part.  But you clearly spent some time putting together the parts you considered relevant complete with comments and illustrations.  That helps a *lot* and it's why I spent some extra time on this one.  (That and the fact that I have some idle time while waiting for a test to finish.)

Items of concern from the snapshots:

AI task:

1. you seem to want to collect the entire cycle duration, starting from one trigger point and ending pretty much exactly at the next one.  This is probably not a workable strategy.  There are some small finite times to account for like trigger delay (time from triggering criteria being met until 1st subsequent sample), and the time to re-arm the trigger after finite acquisition completes. 

   There's a less well-defined (as far as I know) time needed for you to start reading at least some of the data out of the task buffer before the next trigger arrives and wants to try to overwrite it.   I've done quick little tests where this issue doesn't seem to rear its head, but it may depend on the size of the specific device's hardware FIFO (is it big enough to hardware-buffer data until the app has time to read from the task buffer so DAQmx is free to start transferring from hardware buffer to task buffer?)

   You should plan to leave a little bit of "slack time" in there if you want to retrigger off a characteristic from every cycle.   For example, if the region you call "peak time" is the most crucial part, don't trigger off the exact end of that time.  Try to trigger just before the beginning of it.   

   If you really need the equivalent of continuous capture of the entire cycle, you'll need a different approach.  AI should become continuous (and no longer retriggerable) and CO will need to retrigger differently (more on this later).  To help this, I'd recommend you use "Analog Window" triggering instead of "Analog Edge". 

2. reading "RelativeTo" the "Most Recent Sample" isn't an appropriate approach for a Finite re-triggering task.  You probably just delete that property node and stick with the default behavior.   Honestly, I'm pretty surprised that worked, unless you went straight from starting the task to the call to DAQmx Read requesting the full buffer worth of samples.

3. a subtle *possible* problem is that you should query a DAQmx Timing property node for the actual sample rate instead of assuming that the one you request can be implemented exactly.  Related to this is the fact that the external waveform period probably won't be an *exact* integer # of *any* sample rate you can produce.  It's being created by some other equipment with its own timekeeping oscillator and *some* degree of mismatch is inevitable.

CO task:

4. as mentioned earlier, since AI will only trigger once, you need a different way to retrigger.  Once AI is set for "Analog Window" triggering, you can retrigger CO off the "Analog Comparison Event".   Depending on how you define your Analog Window, you could make 1 or 2 cycles of the Analog Event per waveform cycle.  (Do the thought experiment, you'll see why.)  But if the 2nd one happens while the CO task is still busy generating its finite pulses, it'll be ignored and won't be a problem.

   Once again, it'll be important to start the CO task before starting the AI task.  Then you can know that the CO task be triggered the first time the Analog Comparison Event asserts.

(Note: it's possible you could still do this with AI configured for an Analog Edge trigger, I just haven't ever tested the behavior of the "Analog Comparison Event" in that mode.)

5. You should also be careful about the total time defined by your buffer of pulses.  The "timing mismatch" you observe after a few hundred waveform cycles means that you need to *accomodate* that with a buffer of pulses whose total time is just a bit less than the *expected* waveform cycle time.  There's usually a way to construct the set of pulse parameters so that the final pulse time parameter is extra short, so the board can rearm before the next retriggering event.

-Kevin P