Two-edge separation and arm vs. read

[bhpowell]

Apologies for a novice question. I've read several forum posts, and still not sure I follow the best approach for my application.

I am using some 6614 boards.  I've configured nine counters for two-edge separation.

The "start" edge is the same for all nine counters, and I've wired the input pulse to the default "Aux" signal for each of the nine counters.

The "stop" edge is different for all nine, but I've again wired the respective pulses to the nine different "Gate" inputs.

I'm doing rising edge to rising edge time measurement.  This is one-shot--I set up all the counters, wait for the pulses, and then read the time values.

I initially thought that doing DAQmx Start would arm the counters so they would wait for their start pulses, and then I could read the counters later when I knew the pulses had been delivered.  That doesn't seem to be how it behaves, though.

If I Start and then Read with a long timeout, all of the reads measure the two-edge time difference as expected.  So I guess it is the DAQmx Read that arms the counters.

Is there a way I can have Start start the counters, so that I don't have to use a long timeout on Read?

I'm not using the Trigger VI at all.  I've read some about Arm Start Trigger, but I'm not convinced that's the right thing to use.

Thanks for any help.

[Kevin_Price]

So a Start followed by a Read with a long timeout works.  That makes sense, supposing all the edges come in before the timeout expires.

It isn't clear to me what you observed when you simply Start and then wait around a while until you know the edges would have come in, and *then* do the Read.  That should work too.  The counters should arm when you call Start.  The measurement should get "recorded" when the edges arrive.   And they should be available and given to you when you call Read.  So what exactly *actually* happens?

-Kevin P

[bhpowell]

Thanks, Kevin. That’s a good question I should have already answered. 

If I arm, wait for the pulses, and then read, the reads will timeout and return zero. 

I have a loop around the Start calls, but I have to have nine reads in parallel to get values. In an earlier attempt, I looped through nine reads, but the first read saw its pulse, and all subsequent reads timed out.

Brian

[Kevin_Price]

Hmmmmmm.  Curious, I did some really brief tinkering and experiments and think I'm seeing the same thing as you.  Very unexpected.

FWIW, I did this on my only up-to-date PC -- LV 2020 SP1 64-bit, DAQmx 20.1 -- and haven't tried anything elsewhere yet.

I basically just slightly tweaked shipping examples.  2 to manually generate a pulse on demand, 1 to do 2-edge separation measurement of the other 2 counters' outputs.  No triggering.  No calls to DAQmx Timing, which I've long understood to mean that the task should be a one-shot.  Here's what happened instead:

1. Started the 2-edge task, queried Task Done? and got False, called Read with default 10 sec timeout.  Then I manually pulsed the other 2 counters.   The Read returned with a reasonable value, then I queried Task Done? and got False (!?!) again.   
2. Wrapped a loop around the Task Done? and Read calls after a single pre-loop Start.  Each iteration, code would wait at the Read call until I issued the manual pulses.  Then I'd get a new measurement result.  
3. Next I did one iteration the normal way, then manually issued the 1st pulse *before* hitting Read on the next iteration.  After the code progressed to wait at the Read, I issued *only* the 2nd pulse.  This did *not* return a measurement, suggesting that the task was indeed only being re-armed by the Read call.
4. Tried the same kind of thing for the 1st measurement, issuing the 1st pulse after Start but before Read, then issuing 2nd pulse while waiting on the Read.  Same thing, no measurement.

This behavior seems wrong to me but admittedly I really don't do much with one-shot counter measurements -- I mainly deal with continuous sampling buffered tasks on the equipment I support. 

I know that DAQmx Read has an implied "auto-start" behavior.  That could explain what I saw in the 2nd iteration and thereafter.  Well, except that if the task needed to be auto-restarted, the corresponding Task Done? queries should have been True rather than False.  And it also doesn't explain the 1st iteration, where Start was already called and shouldn't have needed a further boost.

-Kevin P

[bhpowell]

Thanks for confirming that you're seeing similar results as me, and that the results differ from our expectations of how it should behave.

I've submitted a service request to NI to see if there's a way to do an arm before the Read.

If I can't, I'll need to do a couple of things...

• Work with my customer to see how big the timeout needs to be for Read.  Maybe a countdown timer--"You've got 60 seconds to send the pulse!  59, 58, 57..."
• Come up with a mechanism to abort the long reads, either because the user wants to cancel and disarm, or because the system figured out that it missed a pulse.  (The pulses all occur within a few milliseconds, so if 8 of 9 counters have returned, the 9th one is probably going to time out because the pulse was missed, and I should just kill it before the 60 seconds.)

[Kevin_Price]

I'm not aware of a mechanism for aborting DAQmx Read once it's called.  If you know or find one, please post back with it.  Same for any good info you get from the service request.

All I know to do is iterate over lots of Reads with short timeouts, then ignore / clear the oft-expected timeout error.  Somewhere in there you can also track your total cumulative wait time to implement your own version of timing out.

-Kevin P

[bhpowell]

A read can be aborted by calling "DAQmx Control Task.vi" with the "abort" command.  I just tested it and it works.  You do get a -88709 error from the Read.  ("The task has been aborted or the device removed from the system.")

I don't like the idea of iterating through reads with short timeouts, since there's always a small window on each iteration where the counters aren't armed.

NI's initial response to my service request matched ours--essentially, "that doesn't seem right".  It's being escalated, and I'll report back when I learn more.

[Kevin_Price]

Thanks, and good call on "abort."  I completely overlooked the possibility of branching the task refnum since it isn't the kind of thing I ever find myself wanting to do.  This might be one of the worthwhile exceptions.

Out of curiosity, what version(s) of DAQmx are you seeing this with?  I've only tried it on 20.1, but we have a number of installed systems that are still at 16.0 and I hope to have time to try the same experiments on one of them tomorrow.

-Kevin P

[bhpowell]

I've been using DAQmx 19.5.

Still no word from NI, other than that they are escalating the issue.

[Kevin_Price · Accepted solution]

At the end of the day I did spot checks on a couple of older systems.

DAQmx 16.0 (Win 10, LV 2016) -  same behavior

DAQmx 9.8 (Win Vista, LV 2013) - same behavior

Unfortunately, it looks like it's been this way for quite a while...

Maybe you could switch to buffered tasks with Implicit timing and then Read just 1 sample (which will be the earliest one, if more than one is in the buffer)?   I'm not around hardware to test now, but I have some optimism.  Most of my counter intution has come from buffered input tasks and continuous generation tasks.  And my intuition is pretty strong that Start should have been enough to arm the counter fully and the subsequent Read should have retrieved an already-latched measurement. 

    Granted, the intuition was *wrong* for your unbuffered task, but I'm still pretty confident it'll be right for a buffered task.

-Kevin P