Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Preprocessing for DAQ Counter Input

Greetings,

I am using an NI DAQ device (USB-6431) to capture angular motion via a three-channel optical quadrature encoder. I have constructed my LabVIEW VI with DAQmx VIs to configure my DAQ (I'm using one of the onboard counters to measure angular position). I noticed throughout the process that there are many built in 'conveniences' that make the setup of the counter quite simple; the VI will automatically process the signals using X4 encoding and Z-indexing with the introduction of a few constants. I am making the assumption that the DAQ device and/or the computer does preprocessing on the input stream before it enters a buffer in order to convert ticks on three channels to values such as '-5.13 radians'. Firstly, is that a correct assumption? Is this is indeed the case, I would like to do some of my own preprocessing to deal with some of the idiosyncrases of my encoder. I am concerned that my computer would not be able to keep up if I do this processing within a LabVIEW loop using the DAQmx Read VI to grab the data from the buffer, so my next thought was to do the processing along with whatever code manages the position measurements from the counter BEFORE it enters the buffer and gets logged to disk. My question is, how would I go about adding this preprocessing behavior to my workflow? I am not at all opposed to writing some C if necessary. I would also appreciate any comments/corrections on my method; I am new to LabVIEW and data aquisition, so I am not sure if this is the right way to go about gathering and processing my data. Thank you for your time.

0 Kudos
Message 1 of 2
(4,576 Views)

Just a few quick thoughts:

 

1. X4 encoding and Z-indexing happens on the board hardware (when configured), no processing involved

 

2. Scaling to radians or whatever is done by the DAQmx driver.  Trivial processing takes place.  (You can also choose to perform a U32 format read to get the raw count value instead of the scaled value.)

 

3. I can just about guarantee that your computer and the DAQmx driver can keep up if you program the data acq and the processing to run in parallel.  LabVIEW makes parallelism pretty easy, to learn more search out the producer - consumer design pattern.

 

4. It won't be productive to try to wedge in some low-level processing between the board and the DAQmx API.  I doubt it's even feasible.   Learning to spin off parallel work with the producer - consumer pattern will let you use DAQmx as is without a hitch.

 

Sorry, no more time now, gotta run.  Hopefully someone will be able to point you to a couple specific examples to illustrate.

 

 

-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 2
(4,555 Views)