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

@Kevin_Price wrote:

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

 


Thank you for your help, sir.  

 

1. I'm not quite understanding you here...  I thought that the 9223 task starts first, so its pretrigger is "armed" and I assume the hardware will sit there and collect data in a buffer.  Then, the 9205 task is armed, and it will trigger upon a certain voltage, which will then trigger the 9223 task.  Shouldn't it not matter how long the 9205 task is running?

 

2.  Maybe my answer to (1) is crazy....  so, I did what you said and now am using the AnalogComparisonEvent from the 9205 module.  I get data, but it triggers on its own and it doesn't record anything but the baseline noise so it's basically triggering right away.  I get 500,000 samples, as expected, but.... maybe the fact that it is triggering on its own is because the task is ending too soon?  

 

This is my first time using these DAQmx task functions so perhaps I don't know what I'm doing....

 

beta_code_3_screenshot.PNG

0 Kudos
Message 11 of 28
(813 Views)

Alright, folks.  Progress, but it will only trigger the 9223 immediately - it is not waiting for a threshold... or is it?  I don't understand what is happening.

 

I attached my code.  I separated the error things so you can see where the error occurs.  I also took out scaling.  I'm doing this as simple as possible to understand the basics here.

 

I am running this today with virtual devices - so the "input" signal is just a 10V sine wave from the dummy devices.  Here is the behavior:

when the trigger threshold is "achievable" both trigger right away, regardless of signal.when the trigger threshold is "achievable" both trigger right away, regardless of signal.

 

When the trigger threshold DOES'T occur, the 9223 triggers anywayWhen the trigger threshold DOES'T occur, the 9223 triggers anyway

So, the 9223 is triggering no mater what.  It's not waiting for the 9205.

 

Why will it not wait until the 9205 triggers?

 

Or am I still misunderstanding what's going on?

0 Kudos
Message 12 of 28
(801 Views)

I haven't been following your code super closely but I'd try to use AIStartTrigger from your 9205, not AnalogComparisonEvent. Maybe AIReferenceTrigger. Have you tried either of those yet?

0 Kudos
Message 13 of 28
(789 Views)

Bro.  I have tried everything.  I've even tried the "DAQmx Connect Terminals" thing to connect the trigger event to the backplane of the 9184, but I can't even access PFI0 on the 9184 so I don't even know how to do that.

 

I think something else is wrong with my code.  I don't know.

 

Or maybe this just doesn't work with the hardware I have.  But I don't see why it wouldn't......

 

Any cDAQ hardware experts out there? 

0 Kudos
Message 14 of 28
(783 Views)

What happened when you used AIStartTrigger? Did it never trigger, trigger too early, etc?

0 Kudos
Message 15 of 28
(779 Views)

@BertMcMahan wrote:

What happened when you used AIStartTrigger? Did it never trigger, trigger too early, etc?


Same exact issue as before. 

 

I feel like I'm misunderstanding something fundamental about the code I have written.

0 Kudos
Message 16 of 28
(776 Views)

@Jay_From_Texas wrote:
Same exact issue as before. 

I can see three places where you had different issues- in one version the trigger never happened, in one place it happened immediately, and in one place your issue was that everything worked fine but the sample rate was too low. Sorry if I didn't follow the chain all the way, but there are like 6 different VI's so I don't know which issue you're referring to.

0 Kudos
Message 17 of 28
(772 Views)

The most recent "beta_code_4"

 

The screenshots I posted above from the waveforms are from that *.vi, just with different trigger thresholds set.

 

The discussion previously (in which it worked "fine") in the thread alluded to putting the cards in the same task and sampling at the same rate (250 kS/s, which is the max rate for the 9205).

 

My goal is to sample at 1 MS/s with the 9223 but use the 9205 to trigger this acquisition, since the 9205 has hardware triggering capabilities.  I am using chassis 9184.

 

Doing an analog edge reference trigger with the 9205 and acquiring with the 9223 at 250 kS/s is straight forward.

 

The latest code I have written is proving troublesome.

0 Kudos
Message 18 of 28
(769 Views)

I want to make sure I'm not getting things confused.  You've posted code and/or screenshots in msgs #4,8,11, and 12.  In msg #12 you stated that you were using "virtual devices" and I *think* you're talking about what MAX would call a "simulated device."

 

Meanwhile, the device names I see in msg #12 match those from msgs #8 and #11.  Only the names in msg #4 are different.

 

I previously thought you renamed the modules in MAX to help in this discussion.  It now sounds to me like msgs #8,11, and 12 are are dealing with simulated devices.

 

If so, then it would make sense that the 9223 acts like it triggers immediately.  That's how simulated devices *always* behave.  See the "Timing and Triggering" section of this article.

 

I saw a good change in the msg #12 code "beta_code_4.vi".  You added a call to DAQmx Read for the 9205 task before clearing it.  Because you're in Finite Sampling mode *and* you didn't specify a # samples to read, you get the default behavior which is to try to read the entire buffer full of samples as defined at DAQmx Timing.  That's 500k samples.

 

I also went back for a closer look at msg #4 code "beta_code_2.vi", now that I'm suspecting that might be the *only* code you posted that uses real physical devices rather than simulated ones.  You posted error text but not the error code #.  What was it? 

 

I still think it looks odd that the terminal constant for "... ai/ReferenceTrigger" uses the chassis name as a prefix rather than a module name.    It seems like that should be a module-based signal, not a chassis signal.  That's what I'm more accustomed to on PXI systems and desktop DAQ boards.

 

I'm gonna go try to go make a simulated cDAQ system to have a closer look at signal routing options in MAX.   More when I get back...

 

 

-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 19 of 28
(763 Views)

Message 11 was the last message dealing with the real devices.

 

Message 12 and onward today is me dealing with this virtually at my office.  I only have access to the real hardware in the evenings.

 

I am so sorry for the confusion.  

 

I would expect it to trigger immediately - sure!  The device is simulated, has no input signal, so the "input voltage" is just an oscillating sine wave.  I was thinking I could "use" that as a virtual test.  But when I put the trigger threshold OVER what that "input voltage" seems to be, the VI gives that error.

 

I thought I did specify the number of samples to read with the sample clock for each task.

 

I attached the latest version in which I put some diagnostics (total samples per channel acquired) into the code to start to try to figure out what the heck is going on.  This is a virtualized device VI.

 

Tonight, and all this weekend, I'll have access to the actual hardware.  My hardware has a microphone that outputs a voltage when it senses sound pressure.  In NI-MAX, I can trigger both cards on the same task at 250 kS/s by clapping my hands.  So the hardware works.  With pretrigger samples.  But not in my ideal 1 MS/s 9223 configuration.

 

 

0 Kudos
Message 20 of 28
(757 Views)