How to increase sampling accuracy?

[randomguy77]

The input signal I'm using is created by hand turning a wheel against a sensor to create a sine wave. Along with the sine input the wheel that gets turned has a reference encoder in it. For each pulse of the encoder the VI takes the current value of the input sine wave. This all works great, except for when you start to turn the wheel fast, at which point the program will start to miss pulses from the encoder causing the sine wave data to be wrong. The board I'm using has a 200kHz sample rate, but having to use four channels so can only sample at 50kHz. That should still be way more than fast enough for a signal that is generated by hand turning something, so wondering if anyone has any ideas as to how to improve the accuracy?

[Bob_Schor]

You are probably doing something very wrong (or very "beginner-ish") with your code.  Attach the VI (please, no pictures unless you know how to make a LabVIEW Snippet) so we can examine your code, find the flaws, and describe them (and how to fix them) to you.

Bob Schor

[randomguy77]

Here is the snippet for the sampling part of the VI. The first loop waits until an index from the encoder. The second loop ensures that data is only being collected while the wheel is spun in one direction, and then stops after 8192, the number of pulses the encoder has per revolution.

[GerdW]

Hi guy77,

as you aren't using standard DAQmx hardware: does your DAQ board support external sample clocks?

- When your encoder gives 8192 ppr (pulse per rev) you can only measure up to 50000/8192 ~= 6 rps ~= 360 rpm (when using as external clock signal). When you need to detect HIGH and LOW of each pulse you are limited to ~180rpm…

- Why do you keep your encoder counting in a float instead of a integer value?

[Borjomy]

If the direction of travel is not important for you and you want to measure the speed more than zero (not in the zero range), you should connect the encoder output to the discrete input of the board counter. Ideally, you need a board type NI 660x, which is just designed for such measurements. At this moment you use an improper tool.

[randomguy77]

The DAQ does support an external sample clock. The DAQ uses 8 bit channels for each digital channel. There is a device between the encoder and DAQ that will convert each pulse from the encoder into an 8 bit number that is usable with the DAQ. When pulling that value LabVIEW registered it as a float, and seemed easier to keep it that way rather than convert it into an int value. It takes about 1-2 seconds to hand spin a full revolution, so it should be more than achievable. 

[randomguy77]

Direct of travel is very important. The reference encoder is paired to a magnet that is connected to a Gauss meter. When turning the device the current Gauss value is taken on each encoder pulse. The time it takes to complete one revolution does not matter at all. What matters is the reading at each spot through one revolution. If the direction of travel changes while capturing the values will be wrong.

[altenbach]

We can't really help form the attached code unless you also include the driver subVIs (assuming we can look at their code). Are these commercial or home-made? How do they influence the loop rate? What is the actual loop rate?

Some code comments:

• You never need to stack two "index array" operations to get a single element from a 2D array. Simply wire both indices! Index array is resizeable, so you can get more than one output if needed. All you probably need is a single "index array" in each loop.
• To wrap at 255, just use U8 datatype.
• There is a "=0" primitive.
• There is a "-1" primitive.
• Do you really need to set the value of the tab control with every iteration of the loop? Where is the reference?
• Does your encoder provide a quadrature signal?
• Yes, you need integer datatypes in most places. There should be very little orange.
• ...