Simple Start Analog Edge trigger doesn't work

[PaulOfElora]

I'm trying to get a super simple analog edge trigger example to work.  I've set up the DAQmx task the same as shipping examples and lots of posts I've seen.  I'm supplying a nice clean DC voltage to a 9205 card using a high quality HP variable power supply.  Using NI-MAX, I've verified that my 9174 chassis & 9205 are working properly.

THE PROBLEM - When I run it, the vi just sails right through to the end, with no error, and an empty data array out.  No matter WHAT crazy voltage I give the "DAQmx Trigger.vi" (set up for Start Analog Edge), it never waits for the trigger to be satisfied, just breezes on through as if it weren't there.  If I set the Sample Clock for "Finite Samples", the DAQmx Read fails with timeout - makes sense, since the trigger wasn't satisfied.  What could I possibly be doing wrong with such a simple task???????

much thanks for any suggestion, paul

[BertMcMahan]

I don't have hardware to try, but a few questions and thoughts to try. I think it's related to your DAQmx Read function. The default value for Number of Samples to Read is -1 if it's unwired (as it is in your code) From the help:

"If the task acquires samples continuously and you set this input to -1, this VI reads all the samples currently available in the buffer. "

This means the function is non-blocking. Since presumably there aren't any samples in the buffer, you'll just read an empty buffer and move on, getting the issue you're seeing. Try changing the "Number of samples to read" to any value other than -1 and see if that works. If not, here are a few random thoughts:

-Does it work in RSE mode instead of Differential?

-Does it work with Finite samples instead of Continuous?

-You said it flies right through- does it wait on the Timeout (5 seconds) or does the whole thing execute instantly?

-Any error shown in the Error indicator?

-Throw some probes on the Error lines after each function. Are there any errors/warnings that are getting "eaten" and not shown by the end of execution?

-Does it work with the 9205 in different slots in the chassis?

[PaulOfElora]

I did probe the errors from the DAQmxTrigger and the DAQmx Start Task - no errors. The execution just blows thru the DAQmxTrigger and the DAQmx Start Task as if they weren't there.  I fiddled with the Finite versus Continous on the DAQmx Timing setup - if I used Continous, the Read would complete with no error, but output an empty 2D array.  For Finite (20 samples), the DAQmx Read throws a -200284 error, timeout.

I haven't tried single-ended measurement, but I did use NI-MAX Test Panels to verify that I was reading the inputs accurately.  I could try single-ended Tuesday (but I think the differential is working fine.

I assumed that the DAQmxTrigger would block until the trigger conditions are met.  Anybody know otherwise?

[Kevin_Price · Accepted solution]

---

@PaulOfElora wrote:

...The execution just blows thru the DAQmxTrigger and the DAQmx Start Task as if they weren't there... 

I assumed that the DAQmxTrigger would block until the trigger conditions are met.  Anybody know otherwise?

---

It is entirely normal and expected to "blow thru" DAQmx Trigger and DAQmx Start Task.  DAQmx Read is the call that might block if you request samples that aren't yet available because the trigger conditions haven't been met yet.  (Or not enough time has passed since the trigger condition to acquire all the requested samples.)

---

@PaulOfElora wrote:

I fiddled with the Finite versus Continous on the DAQmx Timing setup - if I used Continous, the Read would complete with no error, but output an empty 2D array.  For Finite (20 samples), the DAQmx Read throws a -200284 error, timeout.

---

Also entirely normal and expected when you haven't wired a value to the input 'number of samples per channel'.   This was already pointed out in the response from @BertMcMahan in msg #2:

---

@BertMcMahan wrote:

...I think it's related to your DAQmx Read function. The default value for Number of Samples to Read is -1 if it's unwired (as it is in your code) From the help:   "If the task acquires samples continuously and you set this input to -1, this VI reads all the samples currently available in the buffer."   This means the function is non-blocking. Since presumably there aren't any samples in the buffer, you'll just read an empty buffer and move on, getting the issue you're seeing. Try changing the "Number of samples to read" to any value other than -1 and see if that works.

---

Note that when you configure for Finite Sampling mode, the behavior is different.  The default value of -1 *then* means "give me *all* the samples the task was configured to collect at DAQmx Timing, blocking and waiting if necessary."

It's a better habit to always wire a specific value to the # samples input terminal of DAQmx Read, even in the cases where you want to wire in the default value of -1.  I've grown used to the drastic difference in default behavior between Finite and Continuous sampling, but it isn't at all inherently obvious.  Making a habit of always wiring helps make you think about making an explicit decision, which over time will help reinforce your knowledge of the different behaviors.

-Kevin P

[Bob_Schor]

Can you describe the conditions under which you want to start sampling?  I notice that you've wired the signal being sampled as both "the signal being sampled" and "the signal serving as the trigger".  When I've used triggering, I've always used a digital trigger (like a PFI line) -- I'd never thought about using an analog signal as its own trigger, not sure I quite understand how that would work (and I don't have a USB-600x handy to try it out).

Bob Schor

[PaulOfElora]

Much thanks for the helpful suggestions, guys! I'll try/incorporate them 1st thing Tuesday (wish I had the setup at home - but not allowed).

My *intended* behavior is to wait (block) at the DAQmx Trigger/Start Analog Edge on, say channel ai1, until I get a falling edge thru, say, -0.050V.  So I have a little vi (that contains 2 parallel loops) that I want to sit & wait for the trigger to be satisifed.  I'm doing "routine" voltage measurements in another AI loop on a different channel.  I want this vi to run separately from my "routine" voltage measurements because I want the app to respond "instantly" to input voltage exceeding a limit to prevent expensive damage to load cells.  I was afraid that if I used either Finite or Continuous sampling to "catch" an excessive voltage, I might miss it while I'm doing something else.  Yes, yes, a cRIO real-time setup would be better for this, but this is a very cost-sensitive task... I just want to "Arm & Forget" this process until it gets triggered, whereupon it fires an event at me.  SO... I'm also reading the same voltage on channel ai0 for regular-ole voltage measurements, and just jumpering them together.  I did this because I read somewhere that you can't use the same channel for multiple DAQ tasks - I *thought* I would need to set up the tasks differently.  {but now that think about it, the setups can be the same...}.

So my fundamental misunderstanding still vexes me - does the DAQmx Trigger vi not block and wait for the trigger condition to be satisfied, like the instructions state - "Configures the task to start acquiring or generating samples when an analog signal crosses the level you specify"?

[Kevin_Price · Accepted solution]

(Please also see my earlier reply in msg #4.)

The call to "DAQmx Trigger" does NOT block.  It configures parameters related to triggering and does NOT start the task.  It will return quickly and allow the next code to execute.

The call to "DAQmx Start" does NOT block.  It puts the task into its active running state.  It will return quickly and allow the next code to execute.

A call to "DAQmx Read" MIGHT block, depending on details of the task.  This has already been pointed out in msg #2 and msg #4.  You can take control over this by wiring an appropriate value to the '# samples' input.

-Kevin P

[PaulOfElora]

Ok, it's slowly dawning on me.  "DAQmx Trigger / Start Analog Edge" simply *configures the task* for the desired trigger, "DAQmx Start" gets it in a running state, and THEN I sit at "DAQmx Start Task" (yes, with the appropriate # of samples wired), yea verily blocking until the trigger is satisfied.

I do appreciate everybody's patience with me - Tuesday morning I will proceed to open a can of DAQmx whoop-ass on this!

[PaulOfElora]

Oh yeah - and set the timeout of DAQmx to -1

[BertMcMahan]

It's helpful to understand that the DAQmx Task is a parallel process running in a different state from your VI (it runs partly in your computer and partly in the device hardware, but it's basically a "black box").

The DAQmx calls simply configure this task. When the task starts recording samples, they go into a buffer which is read by DAQmx Read. If your DAQmx Read call specifies -1 samples, it reads the whole buffer (if it's empty, it reads 0 elements). If your DAQmx Read call specifies 10 samples, and there are 100 samples in the buffer, it returns immediately with 10 samples. If it specifies 100 samples and there are just 10 in the buffer, it waits until there are 100 samples in the buffer, then returns them (or if the Timeout value is reached first, then it returns everything it can, and gives a Timeout error).

Don't forget- you have to wire the DAQmx Read function with the number of samples to pull from the buffer. DAQmx Timing just configures the buffer*, so you will need to wire values to both Timing and Read to get this to work.

*DAQmx Timing is a little weird about how it configures the buffer- for Finite tasks, it makes a buffer of the size you specify, but for Continuous tasks, it makes a buffer "kind of" the size you specify. It's not super important to understand most of the time, but the Help file describes it pretty well. For now, just use the actual value you want to read when doing Finite acquisitions, and use maybe 200ms worth of data for Continuous reads. If it works, great, if not, you can increase the buffer size a bit.