Best Method for Timing of Event Sequence

[mBrantley]

I am running an experiment that requires a series of events to occur at specific timings. Those events are things like signal generations, TTL outputs, DC outputs, DC ramps, and signal acquisitions. I need these events to happen on sub-ms time resolutions with as little variation from run-to-run as possible (i.e., timing jitter). Additionally, the number and series of events will change regularly.

My first thought is using Timed Sequences, however those are limited in timing resolution and accuracy (Non-RT system) - I may add Hypervisor if that will help. Additionally, the time sequence structure looks difficult to make regular changes to. My next thought was using my FPGA and the backplane triggers - however there are only a handful available on my PXIe-1075 chassis and a single card may have multiple events in the queue.

The existing instrument (that this system will be replacing) shows all the available inputs/outputs on a timeline and I can easily add/remove events on that sequence. I would like to have this level of functionality on our PXIe system.

Can anyone offer suggestions as a best practice for implementing such an event-queue based system?

As I understand it, I have to use the PC to set the triggers on the hardware. If a more elegant solution doesn't already exist, could I load the event list timings into the FPGA - let the FPGA pulse the backplane trigger lines - and then after each trigger have the PC load the next triggered event onto the hardware?

Any input/advice is appreciated. Thanks!

[Intaris]

Attempts to create deterministic routines under a non-RT system are doomed to failure.

Sub-ms timing is anyway a topic for itself under Windows.

Is your work being done mainly on the host, FPGA or over numerous different cards?

[mBrantley]

Hi Intaris,

Thanks for replying. I appreciate your input.

I assumed as much for the deterministic routines - are you saying that even Windows-RT struggles for sub-ms timing?

The actual experiment requires deterministic events occuring over numerous different cards. Even more, some cards have multiple events that are in sequence. I read a little on buffered inputs but haven't tested to see if I could pre-program the trigger sequence on a single card. The host isn't

The FPGA is on a P2P bus with two of the cards - however that still doesn't solve the problem. I am assuming that I can't program the triggers from the FPGA?

While I hope to add more data-dependant experimental stuff - this initial phase only needs a predetermined steps.

Thanks,

[Intaris]

What do you mean my "Windows-RT".  If you mean THIS then please don't confuse this with a real-time system.  I have no idea what RT stands for in this version of Windows but AFAIK it's not "Real-Time".

[OEM_Dev]

The "RT" in Windows-RT stands for RunTime. Windows does offer a real-time system option in Windows CE. I'm not fully understanding what the op is asking but my guess is Windows CE is probably not the right solution.

[Kevin_Price]

You can do some pretty precise and repeatable timing/sync of multiple I/O across multiple boards in a PXI chassis, but you'll generally want to be able to define all the timing relationships upfront before the experiment runs.  Most of the timing and sync would involve setting up buffered data acq tasks that share various timing and trigger signals.  It is generally much simpler to set up this kind of timing and sync if the entire experiment worth of timing relationships can be predefined rather than needing to be worked out on the fly in response to measurements.

That's all kind of a generic statement that a lot of flexibility is potentially available to you, but I really don't understand much about your application needs yet.  You refer to "deterministic events" and "trigger sequences", but I don't know how that translates into signal types and quantities.  Can you give a more detailed description of what you're looking to do?

-Kevin P

[mBrantley]

Hi Kevin,

Thank you for getting back with me. I will try and describe my application in more (relevant) detail.

I have a series of signal generator cards (PXIe-6739 / PXIe-5451 / (4x)PXI-5404) for outputting DC, RF, and Arb signals. These signals are applied (after amplification, etc.) to different electrodes inside of our system at specific times to manipulate the flight path of ions in the gas phase. In a basic experiment, the order of these signals is predefined and the final step is a detection event. I apologize if my use of termonology was incorrect.

Thank you for mentioning the buffer acquisition. My only question is in reference to the DC signals from the PXIe-6739, as this card has multiple (different output channels with different voltages at separate times) events associated with it. Is that still achieveable? The other cards are either single events or retriggerable for the same event.

Thank you for your help!

[Kevin_Price]

Unfortunately, I'm not real familiar with any of the particular boards you're using.  In the couple minutes I had to look at the front product description pages, I *suspect* that you might run into some complications and limitations in setting up timing and sync signals.

My closest experience was to set up a timing and sync scheme across a couple extended PXI chassis (chassis...es?) with a mix of boards including "normal" DAQ, DSA's, timing-controlled communication buses, and a special Timing & Sync board.   There were quite a lot of little gotchas due to, well, lots of reasons including signal delays, restrictions on timebase sources, signal routing limitations, and more.  

I *suspect* (without being sure) that you have some analogous issues between your ARB, your extremely high-resolution frequency generator(s), and your "normal" AO DAQ.  For the investment you have in NI hardware, I'd highly recommend calling on them for some detailed support.  

One further caveat:  much of my scheme was predicated on routing and sharing actual clock and trigger signals, the way I've always been accustomed to doing on "normal" DAQ boards.  There are other sync methods possible that involve setting up boards to phase-lock to a reference clock on the PXI backplane, thus allowing their own internal clock to be used while still staying in sync with internal clocks on other boards that support a similar feature.  I couldn't rely on this because several of my boards didn't support it, but it may work out better in your case.

RE: specific PXIe-6739 question.  I expect this board only has 1 timing subsystem available for AO.   You won't be able to readily have some AO channels react to 1 digital trigger signal while other channels react to another (unless you have time in between the triggers to reprogram).  But you *can* define your AO to always include all channels, while defining the output waveform to output 0V on all the inactive channels.  This kind of approach can work if the AO reacts to the same trigger signal repeatedly, but the active AO channels vary with trigger instance #.

-Kevin P

[mBrantley]

Hey Kevin,

Thanks for your response. Setting up each channels values for each trigger sounds like a perfectly reasonable option. I have a support ticket with NI checking for compatibility with Hypervisor. If I can get reliable 1 ms (sub ppt variation) timing with Hypervisor that would be more than sufficient for our work. However, as with all academic environments - puchasing new software can take weeks (if not months) to actually happen.

I will try to look up more information on trigger instancing - I haven't found any whitepapers showing retriggering where it wasn't the same event occuring each time.

Thanks!

[Kevin_Price]

---

mBrantley wrote:

... Setting up each channels values for each trigger sounds like a perfectly reasonable option...

...I haven't found any whitepapers showing retriggering where it wasn't the same event occuring each time...

---

I'm still not sure we're referring to the same things with our terminology.  What exactly do you mean by an "event"?   Also, are you drawing a distinction between "triggering" and "sampling"?   I treat them very distinctly, which is also the convention in DAQmx.   Not looking to nag, just looking for clarity.

-Kevin P