LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading a single counter with multiple sample clocks

Dear Community,

Is there a way in DAQmx to configure a counter so that its value is read into buffer 1 when external clock 1 goes high and into buffer 2 when external clock 2 goes high? I tried creating two Counter tasks with two different Sample Clocks that use the same physical counter, but this gives me error messages. My problem is that I have several kinds of events that I would like to timestamp using the same counter, so I'd like to keep track not only of when the events happen but which event it was.

I am using a PCI-6254 M-series card.

Thanks!

Casimir
0 Kudos
Message 1 of 6
(3,497 Views)
Casimir,

Greetings! I cannot think of a way to do this, though it may exist. Can you expound a little more on what your appplication is so that perhaps we can come up with a work around to accomplish this?

Regards,
AnujD.
0 Kudos
Message 2 of 6
(3,497 Views)
The application is that we would like to record the value of a 64-bit counter when certain events take place, and we would like to transfer the value of the counter as well as some indication of which event it was, via DMA to the host.

An "event" takes place when a certain DIO line has a rising edge. We anticipate having 3 or 4 types of events, so this means these edges would be coming in on 3 or 4 different DIO lines.

We are also thinking that a 6602/6602 timer card might be a better fit for this problem, although in that case I'm not sure if the counters can be cascaded into 64-bit counters.

Thanks for any tips you can provide! This has been a frustrating problem to work on because it seems like a simple task and there are several solutions
that *almost* work, but not quite.

Casimir
0 Kudos
Message 3 of 6
(3,497 Views)
Cas,

1. A single counter *cannot* be programmed to be sensitive to more than one "sample clock" at a time. Nor, as far as I know, can any of the other DAQmx tasks.

2. I expect you can still accomplish what you need with your M-series board using its timed DIO, counters, and "change detection." I'm afraid I can't describe the exact procedure and syntax, but it goes something like this:
Set up a buffered Digital Input Acquisition. Configure it to use "change detection", in which sampling occurs only when one of the specified DI lines makes a specified transition. (You can specify Rising, Falling, or Either).
Also set up your counters for a buffered edge count. Configure their sample clock to use the DI task's "change detect
ed" pulse. This might possibly be as simple as specifying the DI Sample Clock as the sample clock source in the call to the DAQmx Timing vi. Or it may require some other syntax. It *should*, however, be possible.

What you'd get is 3 synchronized buffers. 2 of them are your low and high 32 bits of your timestamp. The other is the state of the DIO "event" signals of interest at the time given by the counters. With just a simple comparison to the prior sample, you can determine which DIO line changed, i.e., which event happened.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 6
(3,497 Views)
Hi Kevin,

Great to get your help once again on the discussion board!

I was thinking about using the Change Detection feature as you mentioned, but apparently this feature isn't supported by NI. Check out this discussion.

If I can't use change detection, I had another idea, which was to build a little digital hardware that would merge the three event signals together onto 1 line, i.e. make a square pulse every time one of the events happens, then use this 1 line as the sample clock for the counters *and* 3 digital inputs, which would be connected to the lines that signal the e
vent.

My other idea was to use a PXI-6602 or PXI-6608 counter card and just dedicate a pair of (synchronized) counters to each event type. Do you have any experience witht those timer/counter cards? Do you know if you can cascade 2 counters together?

Thanks again!

Cas
0 Kudos
Message 5 of 6
(3,497 Views)
Cas,
Sorry for the bad advice about change detection -- I got fooled by the spec sheets too.

Your digital circuit idea sounds workable, but here are 2 things to watch out for.
1. The first event will produce a finite pulse which acts as sample clock. If a second event occurs before that pulse is complete, you won't generate a 2nd sample because there isn't a transition.
2. A good practice would be to increment your count on the leading edge of the pulse and to sample on the trailing edge (after the increment has registered). With care in your circuit, you can limit your exposure to gotcha #1 above.
Imagine event 2 fires right after event 1. The sample clock can simply be the trailing (falling) edge from a simple multi-input OR'ing of all the events. The one timing problem to watch out for is if event 1 returns to low state before event 2. In that case, your DIO sample would not register that event 1 fired.
I suspect you may need some type of latch or flip-flop between each event and the DIO pin, so any event that fires is latched high until the end of the sample clock pulse.

I'm quite familiar with the 6602 and yes, you can cascade two of them together. But you may not need to. You could perform buffered sampling on just the lower 32 bits, supplemented by a query for the DAQmx Channel Property "Counter Input -> General Properties -> More -> Terminal Count Reached".
The property is smart enough to return a TRUE the first time you query it after a TC has been reached, and FALSE every time thereafter until the next TC is reached. (It didn't used to reset under traditional NI-DAQ circa 6.9.3 so it wasn't possible to count multiple TC's). This will happen slow enough for you to simply observe & count the higher 32 bits in software and not need to tie up a hw counter channel.
If you use a 6602 or 6608, be sure all the counters are configured to start off the same hw trigger signal so their time counts will be in sync.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 6
(3,497 Views)