LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Analog Input Reference Trigger with NI9205 and NI9223 at different Sample Rates

Solved!
Go to solution

I am using the NI9205 and NI9223 card in a cDAQ 9184 chassis.

 

The 9205 supports hardware triggering.  Its max sample rate is 250 kS/s.

The 9223 does not support hardware triggering. Its max sample rate is 1 MS/s.

 

I am physically splitting an analog voltage signal into two parts, to feed both cards, so I can trigger with the 9205 and acquire with the 9223.  I am using an analog reference trigger (rising edge) to start the acquisition.  I need pre-trigger samples because it is a fast transient voltage.

 

When I use NI MAX, this works fine in one single task, but I have to make the sample rate 250 kS/s (because that is the max sample rate of the 9205).

 

Is there a way to split this into two DAQmx tasks such that I can use the hardware reference trigger on the 9205 to acquire pre-trigger samples on the 9223 at 1 MS/s?

 

How do you use a hardware reference trigger from one card to tell another card to gather pre-trigger samples, when the card you want to use is faster than the card with the hardware triggering capability?

0 Kudos
Message 1 of 28
(4,028 Views)

I am using the NI9205 and NI9223 card in a cDAQ 9184 chassis.

 

The 9205 supports hardware triggering.  Its max sample rate is 250 kS/s.

The 9223 does not support hardware triggering. Its max sample rate is 1 MS/s.

 

I am physically splitting an analog voltage signal into two parts, to feed both cards, so I can trigger with the 9205 and acquire with the 9223.  I am using an analog reference trigger (rising edge) to start the acquisition.  I need pre-trigger samples because it is a fast transient voltage.

 

When I use NI MAX, this works fine in one single task, but I have to make the sample rate 250 kS/s (because that is the max sample rate of the 9205).

 

Is there a way to split this into two DAQmx tasks such that I can use the hardware reference trigger on the 9205 to acquire pre-trigger samples on the 9223 at 1 MS/s?

 

How do you use a hardware reference trigger from one card to tell another card to gather pre-trigger samples, when the card you want to use is faster than the card with the hardware triggering capability?

0 Kudos
Message 2 of 28
(4,040 Views)

In short, you likely can't do what you want the way you want if indeed the 9223 doesn't support hardware triggering (which I won't dispute since the summary datasheet makes no mention of triggering capability.)

 

You probably *can* do this by continuously acquiring with the 9223 and looking for triggering conditions in software.  You should plan on using some form of producer/consumer architecture to keep the data acq loop lean and fast. You'll have to be a *little* careful with your coding technique to keep up with 1 MS/sec data, but not too awfully much.   It should be quite do-able.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 28
(3,999 Views)

I read tons of forum posts here saying that if I want to hardware trigger with a cDAQ chassis, I need the 9205 because it does hardware triggering.

 

I can make this work at 250 kS/s with the 9205 alone.  Surely there is a way to make the 9223 start acquiring on an analog reference trigger with pre-trigger samples.  Perhaps I misunderstood

 

Maybe I misunderstood this:  https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6WTSA0&l=en-US

 

The attached code generates the following error:

 

DAQmx Start Task.vi:7220004<append>
<B>Property: </B>Ref.DigEdge.Src
<B>Property: </B>Ref.DigEdge.Edge
<B>Source Device: </B>cDAQ9184-1DF93D9
<B>Source Terminal: </B>ai/ReferenceTrigger

<B>Task Name: </B>_unnamedTask<31>

Does this only work with start triggers?

Does it not work with reference triggers??

 

I tried to change the trigger reference to PFI0 as that Knowledgebase article said and then this happens:

 

DAQmx Start Task.vi:7220005<append>
<B>Property: </B>Ref.AnlgEdge.Src
<B>Property: </B>Ref.AnlgEdge.Slope
<B>Source Device: </B>cDAQ9184-1DF93D9Mod1
<B>Source Terminal: </B>AnalogComparisonEvent

<B>Required Resources in Use by</B>
<B>Source Device: </B>cDAQ9184-1DF93D9Mod1
<B>Source Terminal: </B>PFI0
<B>Destination Device: </B>cDAQ9184-1DF93D9
<B>Destination Terminal: </B>ai/ReferenceTrigger

<B>Task Name: </B>_unnamedTask<4B>

 

0 Kudos
Message 4 of 28
(3,986 Views)

Well, the code and the linked article both have the non-9205 module configured to trigger off a hardware signal.  That's not going to work if the module doesn't support triggering.  That's what it *means* to not support triggering.

 

The small ray of hope is that the linked article refers specifically to *analog* triggering.  While the brief datasheet for the 9223 didn't mention triggering at all, I suppose it's conceivable that it might support *digital triggering*.  Your code attempts to use an internal digital signal that your terminal constant refers to as "/cDAQ9184-1DF93D9/ai/ReferenceTrigger".   This differs from the way you specified your device for the channel names -- it appears you might be missing a "Mod1" at the end of the device name?  If so, try "/cDAQ9184-1DF93D9Mod1/ai/ReferenceTrigger".   Not sure that's the problem -- you shouldn't have been able to select an invalid value from the drop-down menu for the terminal in the first place.

 

Something seems fishy about the fact that your AI channels are designated by identifying devices with a trailing "Mod1" or "Mod4" at the end of the device name while both error messages refer to a device with neither suffix.  Double-check all your names, better yet use built-in DAQmx constants or controls so you can *only* select valid names from the drop-down menu.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 28
(3,978 Views)

I mean, the article says:

 

This task may include other modules that do not support analog triggering, but as long as there is at least one NI 9205, NI 9206, or NI 9775 included in the task, the entire task can have an analog trigger. As with other analog triggering, the trigger source specified needs to be the first channel in your scan list.

From what I've read after scouring the internet for weeks leading up finally receiving all the hardware I bought is that the 9205 allows the PFI0 channel to be "accessed along the backplane of the cDAQ chassis" which I think means allows PFI0 to be accessed by other modules in the chassis for triggering, and that's why people use it to trigger other analog input tasks (even though it is a digital "port.")

 

This guy (using a PXI system) did the same type of analog reference trigger with pretriggers and triggered his other analog input cards using digital reference triggers:

https://forums.ni.com/t5/Multifunction-DAQ/pre-triggering-with-four-PXI-6115-Cards/td-p/2574339

 

I mean, I can do this just fine (just use one task for both cards and trigger with the 9205) if I want to be limited to 250 kS/s.  That works fine with more simple code.

 

But it seems like a waste to have a 1 MS/s card and not even use it.......

 

The "Mod1" isn't shown on the drop-down list.  It is shown on the "PFI0" path though, because that's shared by Mod1 (9205).  All those other terminals are from the chassis.  Mod1 is the 9205.  Mod4 is the 9223.

0 Kudos
Message 6 of 28
(3,975 Views)

Trying to help b/c I've done a lot of DAQ sync work, but admittedly, I have only modest familiarity with cDAQ.  So here are a couple specific questions to work out:

 

1. Does the 9223 support *digital* triggering?  The full manual should make it clear.

2. If so, does it support digital *reference* triggering or only digital *start* triggering?

3. MAX lets you select a device and presents a tab for "Device Routes".  Examine that as well to make sure that the specific signal routing you're trying to do is allowed.  A lot of signals can be shared across the cDAQ chassis, but there can be restrictions and limitations too.

 

Anyone else out there know things?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 28
(3,967 Views)

1.  The 9223 can be triggered by other modules that support triggering in a cDAQ chassis (I've done it).  I can trigger the 9223 when it is in the same task as the 9205.  It spits out pre-trigger samples, just like the 9205.  The analog rising edge voltage signal is handled by the 9205 (that's why I have a 9205 in addition to the 9233).

 

2. If the 9205 can trigger the 9223 with analog, it can trigger it with digital.

 

3.  I'm looking at the cDAQ 9184 chassis Device Routes and I see a lot of things that I don't understand yet....

 

Things I know:

 

I can trigger the whole system with my 9205 (I clap my hands and the microphone I have hooked up to the system sends a voltage to the 9205 and the 9223).  The voltage is over the reference trigger threshold, the 9205 is triggers, the 9223 triggers, and I get samples from both cards at 250 kS/s (max sample rate of the 9205). I do this in NI MAX.

 

The 9184 cDAQ chassis can route the analog trigger of the 9205 along an internal digital line (PFI0). See here:

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6VVSA0&l=en-US

In order to use digital triggering with any task in a CompactDAQ (cDAQ) chassis, you must have a parallel digital input module in order to gain access to the Programmable Function Interface (PFI) lines they provide.
 
  • If you have a cDAQ-9172, you must place the module in slot 5 or 6. These are the only two slots that have access to the PFI lines on this chassis.
  • The more recent cDAQ-9174, 9178, 9179, 9184, 9188 and 9188XT do not have slot restrictions; you may use the digital module in any slot to obtain access to the PFI lines.
  • As an exception to the rule, the 9205 and 9206 analog input modules support using an external analog trigger. This line can be accessed by the chassis (even the 9172) from any slot.
  • The cDAQ-9178, 9179, 9188 and 9188XT have two built-in PFI lines, so if no more than two trigger lines will be required, there is no need for a digital module.


So, the question is........

 

Can I use the analog triggering (reference, rising voltage edge) of the 9205, route it through the PFI0 channel of the 9184 chassis, and use THAT as a reference trigger for the 9223 at its 1 MS/s sample rate?

 

Here's something that I also know works:  If you have a cDAQ-9188 chassis, you can trigger a card by sending an analog voltage signal to the external digital PFI0 port on the chassis!  It's cool.

 

I am home now and using the actual hardware.  I have the code running but it won't trigger.  It just sits there, unless I put a timeout on the "DAQMX Read" function and then it gives me this error (because it's not triggering, of course):

 

beta_code_2.vi<append>
<B>Property: </B>RelativeTo
<B>Corresponding Value: </B>First Pretrigger Sample

<B>Task Name: </B>_unnamedTask<28>

beta_code_2_screenshot.PNG

0 Kudos
Message 8 of 28
(3,962 Views)

I do not have any answers for your problem, but ...

When you combine all the Channels in one task, the DAQmx API uses "Channel Expansion" to synchronize, trigger, etc, all of the modules together in a single task. You are limited by the 9205 Sample Rate because synchronization is limited by the slowest sample rate.

Not sure if this will work, but you might be able to peak into the synchronized single task that works using DAQmx property nodes to see what the trigger source is, trigger name, etc, that you can try that in your beta program.

 

mcduff

0 Kudos
Message 9 of 28
(3,956 Views)

Ok, gotcha, sounds pretty clear that the 9223 supports digital reference triggering, and can get a digital trigger signal from the 9205 via the cDAQ chassis.  Two more thoughts for you:

 

1. You're clearing your 9205 task almost immediately after starting it.  When the analog triggering condition arrives, it'll be too late because the 9205 isn't active any more.  And thus it won't generate any signal that the 9223 can receive.

 

2. The use of PFI0 seems wrong.  Your first code that used .../ai/ReferenceTrigger seemed more sensible.  Another thing to try might be the "Analog Comparison Event".  You may need to right-click your terminal constant, chose "I/O Filtering...", and then enable "Advanced Terminals".  If you find it annoying that NI kinda hides this, give kudos to this idea like I did several years ago.

   You might also be able to do explicit routing using functions like DAQmx Export Signal, but I don't know the cDAQ platform well enough to give more specific advice.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 28
(3,941 Views)