Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Buffered edge counting armed periodically armed

Solved!
Go to solution

I am trying to determine whether the following is possible on the NI-6363 (and like devices).

 

  • Buffered edge counting
  • armed with an external signal (e.g. 100 Hz 50% duty cycle digital signal) to reset the counter
  • “Input signal” on the order of MHz driving the counter
  • Sample clock signal is random with periods and pulse widths of many times the input signal period which may or may not occur in an armed time period
  • Buffer detected edge counter values returned for each armed period

 

i can perform all of the above but the last point.  The number of detected edges are not constant within an armed period and the counter is reset.  

How can I get from a single read all of the detected edges in that time period?  Can I trigger the buffer transfer somehow with the signals I have access to?

0 Kudos
Message 1 of 7
(2,821 Views)

I'm not totally clear on what you're describing or what you need.  Responses inline in red.

 

  • Buffered edge counting

Yep, sure.

 

  • armed with an external signal (e.g. 100 Hz 50% duty cycle digital signal) to reset the counter

Arming and resetting are two distinct kinds of behaviors.  What do you mean here?

 

  • “Input signal” on the order of MHz driving the counter

Ok, yep.

 

  • Sample clock signal is random with periods and pulse widths of many times the input signal period which may or may not occur in an armed time period

Probably ok, but depending on what you mean in the latter part of that description, you may need to deal with the "duplicate count prevention" property.

 

  • Buffer detected edge counter values returned for each armed period

Counts per interval could be measured with either an edge counting task or a period measurement task, depending on which signal goes to which counter terminal.  Period measurement does the count reset for each interval internally.   But it isn't hard to do finite diffs on edge count data externally.

 

i can perform all of the above but the last point.  The number of detected edges are not constant within an armed period and the counter is reset.  

How can I get from a single read all of the detected edges in that time period?  Can I trigger the buffer transfer somehow with the signals I have access to?

As stated in the last answer.  Edges per time period is most naturally measured by configuring a Period measurement task.  But an Edge counting task is generally more straightforward to configure, and only requires you to do a simple software finite difference to produce the same data.


-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).
Message 2 of 7
(2,808 Views)

Thank you Kevin for the feedback.  I have diagramed what I am attempting to do here.

 

 

counter.png

 

I have data acquisition periods defined by the "counter reset" signal illustrated above.  Within these periods, I need to determine the time of signals acquired on the "sample clock" signal.  Within these periods I may detect zero, one, or many edges.  At the conclusion of the data acquisition period, these need to transferred.  In practice, I will be creating and synchronizing a few of these counter channels and need to calculations on the edges detected the synchronized channels.

 

I have developed this similar approach on a micron controllers using interprets.  I understand these DAQ devices aren't quite as configurable, but if I can get this or a similar data acquisition configuration to work it may save me some time in prototyping.

 

I can get bits and pieces of this to work, but not as diagramed above.

 

Thank you.

 

 

0 Kudos
Message 3 of 7
(2,768 Views)

One roadblock is that you, the app programmer, can't control data transfer to happen on a particular hardware signal.  The DAQmx driver manages data transfer from the device to your task buffer.

 

Your job is to add some smarts to your software so *you* can separate data into chunks that represent each interval between resets.  But I can see how that may not be guaranteed to be unambiguous.  You might get a reset after sampling a 1 count, and then another reset and lots of inputs occur before the next sample where the count is 5 count. Up in the software, you have no way of knowing that you missed a reset because all you see is a continuously increasing count that *looks like* no reset occurred.

 

So you may need to add another, largely redundant counting task for the sake of resolving this ambiguity.  I may need to think about this a bit more to have some specific suggestions for you.

 

Meanwhile, let me suggest you start learning about the "Arm Start" trigger that will be needed to sync 2 counter input tasks.  A good share of your search results on the forum will probably be threads I was in.  😊

 

 

-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).
Message 4 of 7
(2,732 Views)
Solution
Accepted by topic author stayj

It turns out that the "helper" task can be simpler than I first thought.  It'll just be another edge-counting task where you count edges of the sample clock signal and use the reset signal as a sample clock.

 

Each count value that gets buffered is a cumulative # of sample clock edges occurring by the corresponding reset edge.  So you can use a simple finite difference to tell you the # of samples *within* each reset interval.  That result then tells you how to group the data from your original task -- the # samples belonging to each reset interval

 

I'd have liked to make this a period measurement task to avoid the software finite difference, but an ill-advised design decision would cause a period measurement task to ignore initial behavior and complicate the process of sync'ing the tasks together.

 

Speaking of sync'ing the tasks, both tasks need to use an "Arm Start" trigger that your code should control (so it can't assert until both counter tasks have been told to start).  I typically do this with a DO line that doubles as a PFI pin.  I set the DO line False before starting either counter task, then after starting both counter tasks I toggle it True and then False again to make a brief pulse.

 

I modified a shipping example that I didn't post last time once I realized the ambiguity you'd still be stuck with.  I'm posting it now after adding config for the "Arm Start" trigger.  This should be your main counter task, not the the "helper" task. 

    The helper will have a simpler config that uses some of the same signals for different purposes as described earlier.  You'll want to read it in the same loop so you can properly group the data from your main task in terms of # samples per reset interval.

 

What's left is to add the simple DO task for generating the Arm Start trigger signal, and getting the task sequencing right.

 

 

-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).
Message 5 of 7
(2,707 Views)

Thank you very much Kevin for taking the time to look at my problem.  I have recently (year or so) starting using more of the functionality of these DAQ devices.  What I have started to realize is they don't provide the determinism that I am used to having access to in more traditional microcontroller architectures (interrupt driven basically).  That determinism as you are suggesting and I have implemented on other projects has to be controlled in other ways.  Certainly a different way of thinking.

 

I have to take some time and absorb your suggestion and look at the code to see if it can ultimately fit my application.  I'l be back with some thoughts.  Thanks again!

0 Kudos
Message 6 of 7
(2,674 Views)

Kevin is exactly right.  Using two timers is the best path for getting this data.  One counter to capture the number of events during the data acquisition period and the other counter to report the timing of those events.

 

I didn't end up developing code for this in the end other than a small proof of concept VI, because ultimately I don't have enough counters to do the job with 3+ channels of data that need to be analyzed.  Ultimately I will go with a more traditionally microcontroller approach that doesn't require two timers per channel, and also provides more timer channels.

0 Kudos
Message 7 of 7
(2,602 Views)