How to handle dropped pulses?

[vchu]

Hi, I am relatively inexperienced in LabVIEW programming. I am using NI USB 6002 to read from a rotary encoder to track shaft angle. I am noticing that sometimes if the computer is busy processing something else and the encoder shaft has been moved, encoder pulses are dropped, resulting in inaccurate angle information. How do I ensure that no pulses are dropped, even if I need to store them in buffer to update the angle later when processing power is available again? I am currently using DAQmx Read in a while loop to read encoder data.

Thanks.

[Kevin_Price]

Good news and bad news.  

Good: The count register in a counter task will increment independently of your CPU.  When you read from the task, you'll retrieve the instantanous value of that register.  If your CPU gets bogged down, you won't *notice* every increment, but they'll all get registered.

Bad: Your board can cover only minimal counter/encoder needs.  You can't buffer position vs time, you can't detect direction changes, you could accumulate *very* large errors if your device oscillates about a particular encoder edge.

Meanwhile, post your code .  It'll help one of us to help you better.

-Kevin P

[vchu]

Hi Kevin, 

Thanks for your input. If I am understanding you correctly, by using a counter read as a backup, I can check how many counts I missed, but cannot determine direction. 

I have attached a screenshot of the code. 

Virginia

[Kevin_Price]

It appears from your code that you have 4 encoder signals -- 2 each from 2 different encoders.  Your board has 1 counter that can handle only 1 signal.

Most encoder apps have signal rates that are too fast for a DI task on a low cost USB board.  Odds are, yours will be one of those too.  You're very likely going to need more capable data acq hardware to have any realistic shot at tracking position on 2 quadrature encoders.  

I'd start by looking at an X-series board.

-Kevin P

[Minions]

Look at your encoders and determine how many pulses per revolution they have.  Then determine how fast they are going to spin (RPMmax).  During a sampling, only A or B may change never both.  This means that for each cycle of A in the same direction, 4 edges have occurred [AB, AB, AB, AB, then repeat with AB] (Strikethrough used to imply inverse or not state).  What does this mean?  Each pulse has 4 edges or states occurring.  An encoder with 1,000 pulses per revolution actually has 4,000 states or edges per revolution.  Your chosen instrument must be capable of taking = { [Spin(RPMmax) * (1 minute/60 seconds)] * [4 * Encoder(Pulses per Revolution)] } ==> Samples per second minimally.  Preferably, it should be able to sample 2 times more just to avoid any sampling on an edge barrier.  This is in order not to miss any pulses.

[vchu]

Thank you for the suggestion. I made the calculations to ensure that I am sampling fast enough. The problem is when the program is held up by another action, e.g. saving data to file, and if the encoder has been moved during that time, pulses are dropped, and the position is lost and not updated. Currently, I am re-calibrating every time after saving data to file, but I wanted to see if there is a way to still buffer the pulses during these incidences. 

[vchu]

Yes, I have 2 signals from each encoder, and 2 encoders total. The 2 signals are for determining direction depending on which pulse comes in first. I do not have a very fast spinning application, and I did the calculations to make sure the low cost boards are fast enough to handle the task. My problem is when the program is saving file or doing something else that it stops buffering/reading pulses. I am not sure if upgrading to an absolute encoder would be my only option. 

[Kevin_Price]

There are ways to structure your program (producer - consumer pattern) such that saving data has minimal effect on your data acq rate.

That said, your board doesn't support buffering, doesn't support quadrature, and has a pretty limited polling rate over the USB bus.  I'm kinda doubtful you'll be able to get reliable results by polling digital states.

In fact, you might be fortunate that you've already seen such obvious issues caused by file saving.  A system that fails frequently and in a predictable way is much simpler to diagnose.  The lurking failure modes that you could encounter polling digital states over USB may well be much less obvious and result in wrong but plausible data.  Wrong but plausible is a bad place to be.

-Kevin P