Differentiate Sampled Position

[hormel13]

I'm trying to differentiate a sampled position signal to get velocity.  I've attached a screenshot of what I've written thus far. The displacement is determined by by using a shift register to subtract the previous position from the current. The time in which that displacement occurred also uses a shift register to calculate difference in time.  The time is kept track of with a Tick Count VI.  is this method is good?  Another method I thought of was to divide the displacement by the sampling rate fed to the DAQmx timing VI.  

[Bob_Schor]

How are we supposed to "edit" a picture?  How are we supposed to be able to "run" a picture?  [Hint -- attach your VI].

You should not use the LabVIEW/Windows timers to compute Elapsed Time.  Your DAQ device has a much better clock, one not bothered by file I/O, Windows Updates, etc.  It is also a constant, so you don't need to keep calculating it on each loop.

Bob Schor

[Kevin_Price]

I agree with Bob (as usual).  A few additional thoughts:

- you have a sign reversal in your "Change in Distance" calc, you're calculating (Previous - Present) instead of the reverse.

- getting your timing info from the DAQ task is *definitely* the better approach for determining your time interval

- the best way to determine your DAQ sample timing is by querying a DAQmx Timing property node for the sample rate *after* you call DAQmx Timing.vi.   That will tell you the *actual* sample rate being used, which may be a little different than what you asked for.

   The reason why is that most popular DAQ devices don't support infinitely variable sample rates.  A fixed frequency timebase is typically divided down by various integers to support discrete sample rates.

   If you request a sample rate that would need a non-integer divisor, DAQmx will use the neighboring integer and sample at a rate that's *close* to what you asked for but not *equal*.  So the sample rate you ask for is not necessarily the sample rate you get.

   (An alternative is to call the waveform version of DAQmx Read.  The "dt" field of the waveform will also reflect the actual sample rate rather than the requested one).

   Final note: your specific sample rate of 1000 Hz is likely one that can be supported exactly.  But it's an important good habit to learn that you need to query the task to discover the *true* sample rate.

- at present, you're reading multiple samples at a time and calculating a single average velocity.   This can be fine, the averaging will make it less erratic.

   Don't forget that when you query the sample rate or "dt" value from the task, you'll need to multiply that by the # of sample intervals to get your overall delta time.  This is a classic area for "off-by-one" errors.

   Here you get lucky.  If you read N samples each iteration, then that segment of data has (N-1) intervals.  But you *also* need to account for the interval from the last sample of the previous iteration until the first sample of this iteration.  Add this 1 interval to the (N-1) and you get back to a total of N intervals since the previous loop iteration.

-Kevin P

[hormel13]

I've attached my .vi with some of the changes suggested.  Ignore the "Potentiometer" measurement and the analog output on the bottom.   

-I fixed the sign reversal

-I added a DAQmx property node to get the actual sample rate.  Did I implement it correctly?

-I don't fully understand how the "number of samples per channel" works.  You mentioned that I'm reading multiple samples at a time and calculating a single average velocity.  But I haven't written any averaging code.  Is this done automatically if I read multiple samples at a time into the while loop?  I've almost convinced myself that I'm calculating the velocity from the Nth position sample and throwing away the previous N-1 samples.  

-

[Kevin_Price]

- the query for actual sample rate was correct, but you then calculated the time period for a *SINGLE* sample interval.  You would have needed to multiply that by the # of intervals to get the total delta time

- Neither you nor DAQmx were *explicitly* averaging.  It's the technique itself that has the *effect* of averaging.  You were calculating a total delta position across N samples and a total delta time across the same N samples.  By definition, that gives you an *average* speed over that time interval.

I made a couple simple mods for you, but when trying to backsave to LabVIEW 8.x (where you started from), I got a few errors because some stuff couldn't convert back.  I've included a block diagram screenshot here because I don't know how usable the back-converted vi will be.

The main changes were:

- specify a fixed # samples to read.  I used a common rule of thumb to ask for 1/10 sec worth of samples each iteration

- I read the AI data as a waveform so that the timing info would be included

- I calculated (average) speed by doing a linear fit of the N samples.  The slope of position vs time is speed.

-Kevin P