Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Capture encoder value on digital input.

I am using a PXI-6221 DAQ card and LabVIEW 2012.

I have linear encoder that gives a quadrature signal and I have four proximity sensors that give a digital output.

I have successfully implemented example code that runs a while-loop and updates a display of the encoder position and digital inputs at regular interals.

I would like to capture the exact encoder value when each of the four digital inputs changes state. The simplest method might be to have the loop compare the previous state of the digital inputs via a shift-register and save the encoder value if there is a change. I would prefer to use hardware-triggering to get a more acurate measurement. Is there any example code that does something like this?

0 Kudos
Message 1 of 5
(4,495 Views)

Your board supports digital change detection as one of its hw-timed sampling modes.  You need to set up a DI task based on change detection, and then set up an encoder task that uses an internal "change detection event" signal as a sample clock.

 

I've attached a LV2013 snippet to illustrate main points, you may need to wire up some other inputs for encoder scaling, etc.  Since DI samples are only taken when there's a transition on one of them, I do a quick sneak preview of the DI lines before doing the main config.  Then you'll have something to compare to when the first transition happens to let you know which sensor changed state and in which direction.  This assumes that you'll start this program before starting motion on the system you're characterizing.   Also note that the encoder task is started before the DI change detection task, making sure both are running when the first ChangeDetectEvent occurs.

 

Hope this helps you get started...

 

 

-Kevin P

 

encoder on change detection.png

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 5
(4,473 Views)

Thank you Kevin, this was exactly the start I needed. I had a chance to try it today and got quite close to what I needed. Here is my code so far:

Capture Encoder

I had to change "Digital 1D Bool 1Chan 1Samp" to "Digital 1D Bool NChan 1Samp". I also found that "nominal transition rate" needs to be the maximum transition rate expected otherwise I was getting Error 200284 'Some or all of the samples have not yet been acquired.'

I have managed to run this code with my test system and the data that comes back looks like what I expect. My only problem is that the number of samples "DI Samples" and "Counter" samples don't always match.

Thanks again.

0 Kudos
Message 3 of 5
(4,451 Views)

Only time for quick comments:

 

1. Looking at the way you're waiting for a while and then doing a one-time bulk read of samples, you might be better off doing Finite Sampling.    

 

2. Your error was likely caused by waiting too long before hitting the stop button that initiated the Reads, not directly by estimating too low a nominal sample rate.  (In an indirect way, the claimed sample rate can affect the auto-sizing of the Continuous Sampling buffer when you leave the input unwired.  With Finite Sampling, you aren't allowed to leave the size unwired.  

 

3. Also, when you leave the '# samples to read' input to DAQmx Read unwired, it has a specific meaning.  For Continuous Sampling, it means "read all available samples".  This explains why you don't always get the same # of samples from your two tasks -- you're asking for "all available" at two slightly different times.  The 2nd task to be read might have collected some extras after the 1st task was read.  A good workaround would be to read all available from the AI task, take the array size and request that same # samples from the DI task.

   When doing Finite Sampling, the meaning would be "read the entire buffer size worth of samples".  If you define both buffer sizes to be equal and do Finite Sampling, you'd get the same # of samples from both tasks.  Well, as long as you don't time out.  That's another Read input you may need to wire.

 

 

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

Thank you for your comments Kevin. Finite sampling does work out better. I now have a piece of code that captures exactly the data that I need. I include it here for the benefit of anyone reading this thread in the future.

Reed_Capture_-_Finite_samplesd.png

Thank you for you help.

Message 5 of 5
(4,401 Views)