06-13-2019 11:35 PM
@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....
06-14-2019 11:23 AM - edited 06-14-2019 11:24 AM
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:
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?
06-14-2019 01:34 PM
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?
06-14-2019 02:17 PM
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?
06-14-2019 02:31 PM
What happened when you used AIStartTrigger? Did it never trigger, trigger too early, etc?
06-14-2019 02:42 PM
@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.
06-14-2019 02:45 PM
@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.
06-14-2019 02:50 PM - edited 06-14-2019 02:55 PM
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.
06-14-2019 03:03 PM
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
06-14-2019 03:20 PM
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.