Analog Reference Trigger on 9205 with 9223, but with different Sample Rates on each Card. How to Pretrigger?

[Kevin_Price · Accepted solution]

I made a simulated cDAQ system and am not liking what I see in the device routing table. First here's the chassis:

And next here's the 9223 module.  It seems to "own" no timing signals at all.  (The 9205 owns only PFI0 and its AnalogComparisonEvent.)

What I see suggests that the chassis owns the signals and timing engine for AI.  Digging in a little further though, I also see timing signals designated for "te0" and "te1".  A little searching led me to this article.  And now I'm back to feeling better about things again.

The signal named "...ai/ReferenceTrigger" would be owned by one of the ai timing engines, the online help says that the one called "ai" is timing engine 2.  There's a similar signal named "...te0/ReferenceTrigger" that would be owned by timing engine 0.

When you try to configure 2 distinct AI tasks, the article suggests that DAQmx will automatically know to reserve a distinct timing engine for each.  But if you leave it up to DAQmx to do automatically, you don't really know which task (if either) uses ai, te0, or te1.   And if you don't know which timing engine the task uses, you don't know which signal to pick from the drop down list.

So maybe the fix is for *you* to explicitly designate the timing engine to use for each task.  This can be found under the Advanced section of a DAQmx Timing property node.

Here's modified code that sets the 9205 to use timing engine 0.  Then in the config for the 9223, I call for "...te0/ReferenceTrigger" to be used as the digital reference trigger signal for the 9223 task.  The 9223 is configure explicitly to use timing engine 2, the one referenced as "ai".   I did some minimal wire cleanup too.  Can't promise this'll work, it's my first time ever trying to mess with specifying cDAQ timing engines, but let's give it a try.

- Kevin P

[BertMcMahan]

Can you use the Reference.Terminal property node to retrieve the autoconfigured Reference terminal for the "master" task, then wire that to the Source terminal for the "Slave" task? That would solve the issue of needing to specify analog timing engines explicitly.

Also, wouldn't you want the Master device to just use a Start, not a Reference, trigger? I suppose it wouldn't matter either way, but it seems like Start triggers have been a little simpler in my experience. The Slave device would still need a Reference trigger since it needs pretrigger samples.

Sorry I can't offer too much help... I don't have the hardware I'd need to actually run this, and simulated devices aren't great with triggers, so it's all guessing. Kevin's code looks like it'd work to me, but I always hate using explicit names for terminals. It seems to always bite me later on, so I generally try to read terminals from property nodes if at all possible.

[Jay_From_Texas]

Thank you for your help. I will examine it later tonight and tomorrow.

In the meantime I also found this:

http://www.ni.com/product-documentation/54452/enhttp://www.ni.com/product-documentation/54452/en/

[Jay_From_Texas]

---

@BertMcMahan wrote:

Can you use the Reference.Terminal property node to retrieve the autoconfigured Reference terminal for the "master" task, then wire that to the Source terminal for the "Slave" task? That would solve the issue of needing to specify analog timing engines explicitly.

Also, wouldn't you want the Master device to just use a Start, not a Reference, trigger? I suppose it wouldn't matter either way, but it seems like Start triggers have been a little simpler in my experience. The Slave device would still need a Reference trigger since it needs pretrigger samples.

Sorry I can't offer too much help... I don't have the hardware I'd need to actually run this, and simulated devices aren't great with triggers, so it's all guessing. Kevin's code looks like it'd work to me, but I always hate using explicit names for terminals. It seems to always bite me later on, so I generally try to read terminals from property nodes if at all possible.

---

Good questions. I am replying on my phone right now and didn't see your reply before my last reply to Kevin.

Perhaps using a start trigger on the 9205 will work if I still use a reference trigger on the 9223 that references what the 9205 does. You've given me more options to try.

You guys are great. Gonna take a look at this later tonight.

[Kevin_Price]

FWIW, I like the suggestion from BertMcMahan for sharing the trigger without using a terminal constant.  I'd suggest you try that first, it's a better approach to get in the habit of using.  I almost always do it that way too, I was just kinda locked in on the idea of making minimal changes to your code.   

-Kevin P

[Jay_From_Texas]

---

@Kevin_Price wrote:

I made a simulated cDAQ system and am not liking what I see in the device routing table. First here's the chassis:

And next here's the 9223 module.  It seems to "own" no timing signals at all.  (The 9205 owns only PFI0 and its AnalogComparisonEvent.)

What I see suggests that the chassis owns the signals and timing engine for AI.  Digging in a little further though, I also see timing signals designated for "te0" and "te1".  A little searching led me to this article.  And now I'm back to feeling better about things again.

The signal named "...ai/ReferenceTrigger" would be owned by one of the ai timing engines, the online help says that the one called "ai" is timing engine 2.  There's a similar signal named "...te0/ReferenceTrigger" that would be owned by timing engine 0.

When you try to configure 2 distinct AI tasks, the article suggests that DAQmx will automatically know to reserve a distinct timing engine for each.  But if you leave it up to DAQmx to do automatically, you don't really know which task (if either) uses ai, te0, or te1.   And if you don't know which timing engine the task uses, you don't know which signal to pick from the drop down list.

So maybe the fix is for *you* to explicitly designate the timing engine to use for each task.  This can be found under the Advanced section of a DAQmx Timing property node.

Here's modified code that sets the 9205 to use timing engine 0.  Then in the config for the 9223, I call for "...te0/ReferenceTrigger" to be used as the digital reference trigger signal for the 9223 task.  The 9223 is configure explicitly to use timing engine 2, the one referenced as "ai".   I did some minimal wire cleanup too.  Can't promise this'll work, it's my first time ever trying to mess with specifying cDAQ timing engines, but let's give it a try.

- Kevin P

---

Kevin. You are the f*cking MAN.  I now see two plots, triggered, one from a 250 kS/s acquisition and one from a 1 MS/s acquisition. I could kiss you. But I'm not going to.  I would totally buy you a beer though, if we met.  You are the man.  It worked.  Explicitly defining the timing engines worked!  I clearly do not know enough about cDAQ chassis timing, but I sure as hell do now!  I bet this is going to help so many people!

Bert - also, thank you so much for the help.  I think I know how to ask the master task which timing engine it's using... but... how do I then tell the reference trigger on the slave task to use the proper terminal? How do I tell it that timing engine "X" corresponds to terminal "Y?"  For example, if it really used "0" (which is now being explicitly defined), how do I tell the slave reference to use "te0," without knowing it used "0" in the first place? (because 0 corresponds to te0). Would I create a table of values, as below, and then query the table?

The SampTimingEngine attribute/property is an integer value corresponding to one of the three analog input timing engines available on the chassis:

SampTimingEngine Value	Timing Engine Used
0	te0
1	te1
2	ai

Ok, now to make my code do cool stuff, like:

- Figure out how to reset the trigger 

- Plot the data in user-friendly ways

- export the results to spreadsheets or other data files

- find peaks and report them on the screen and in the files

- write reports with Word or Excel

I see a lot of people make nice front panels - I suppose there are also fancy templates or color schemes/graphics that make charts look more modern. 

[BertMcMahan]

Give this a shot. I'm not getting *quite* what I expect from the simulated hardware I have in MAX but it might work with the real thing.

I realize the Slave task should be started before the Master task, but the Start Terminal property node isn't valid until the task starts. It's probably fine here though as the time offset will be super small.

[Kevin_Price]

I was just fiddling with simulated devices here too and had pretty much the same thing in mind.  Only 2 additional comments:

1.  You can make a call to DAQmx Control Task to "commit" the 9205 task without starting it.  You can then validly query the trigger terminal and still start the 9223 slave task before the 9205 master task.  (As mentioned in "explain error" when I got one initially by trying to query the 9205 task too early.)

2.  You should generally get the same 9223 behavior whether the 9205 is configured for Start Triggering (as shown) or Reference Triggering (as you started out with).  It'll probably be easier for you to confirm your timing and sync if you switch back to Reference Triggering though.

   There's the tiniest of chances that it could be important to do Reference Triggering based on the following unlikely (but possible) scenario.  I don't believe that a reference triggered task will respond to a trigger signal until after it has acquired the specified # of pretrigger samples.  When both devices use reference triggering with the same amount of time worth of pretrigger samples, you can't miss signal at the 9205's trigger terminal.   If the 9205 uses Start Triggering, it's *conceivable* that the trigger signal could assert before the 9223 has buffered the specified # of pretrigger samples, causing the 9223 to ignore it.  

-Kevin P