DAQmx Angular Encoder Velocity

[Corey.Rotunno]

I am using the "CI Angular Velocity" DAQmx task with an NI9361. It works for the most part. However, I am running into a problem where the velocity value hangs at the last valid measurement. In practical terms, this means if the encoder comes to a sharp stop, then the velocity continues to read whatever value it was at before the encoder stopped.

This is always an issue when taking frequency type measurements. Normally specifying the "CI.MaxMeasPeriod" property on the task takes care of the issue; if the time since the last pulse received exceeds the maximum measurement period, the frequency measurement value is artificially set to a value of 0. I would expect the same behavior out of encoder velocity. However this same method is just not working.

For now, I am using some dirty logic to set the value to zero after the task read if the encoder position value hasn't changed in a second or so. I would like a cleaner solution. I could just use a frequency task and scale into deg/s but I also don't like that method. If anyone has any tips they could share with me that would be greatly appreciated. 

Thanks,

Corey

[mterz]

Corey,

What values do you have wired into some of those other properties, such as the CI.Velocity.MeasTime? Also what timing and acquisition methods are you using for your task?

[Corey.Rotunno]

Madison, 

  I am using .006667 seconds for my measurement time with a divisor of 100. My timing is set to give me continuous samples at 10kHz (I know that I am over sampling by a factor of about 100 below a certain frequency threshold, this is just to make it easier on me to match it up with my analog tasks). The task is setup as am "Angular Encoder Velocity" DAQmx task and the acquisition is a standard CI DAQmx read. Being that it is the weekend I dont have my VI infront of me, but Ill post my task setup and read VI's when I get back to work.

As a side note incase you are not familiar with the NI9361 - reading from a NI9361 differs from reading most other counters. The NI9361 allows oversampling and does not force implicit timing on the task. Also, you can stick multiple counters into the same task instead of creating individual tasks for each counter. Reading from it is much the same as reading from any analog input. I love this module.

[mterz]

Corey,

I just found this document, which verifies that your initial solution is just for frequency measurements, and would not work the same for velocity ones.

Counter Input Maximum Measurable Period Property

http://zone.ni.com/reference/en-XX/help/370469AG-01/daqmxprop/attr3095/

Other modules also have that same behavior of buffering the last valid value, however, 0 should be a valid measurement. Do you see the same behavior if it is a gradual stop as opposed to a sharp one? Also, you mentioned that it is not forcing implicit timing; do you have it set as implicit or a different clock?

[Corey.Rotunno]

Madison,

Thanks for the link. I know it doesn't say absolutely the CI.MaxMeasPeriod should work for velocity, but I was hoping it would. It allowed me to set the property without throwing an error, so it seems like NI may have intended for it to work with velocities as well.  0 is a valid measurement to us humans, but counter cards seem to have trouble deciding when it is truly 0.... they just sort of hang out waiting for the next pulse.

I am using a 10kHz clock, not implicit timing. I am oversampling it. 

Regarding the gradual vs. sharp stop, it doesn't seem to matter although I do not have a great way to ensure an absolutely gradual stop; at some point it has to stop moving. I am seeing interesting behavior though; at my actual test setup I get this issue probably 25% of the time it comes to a stop. Using the same encoder, cDAQ chassis, NI9361 module, and identical code at my desk, I can't get it to reproduce the problem. However, at my desk I have the advantage of using my fingers to turn the encoder, so maybe the stops aren't as "sharp" as they are on my test rig.

For now I am just setting velocity = 0 if the position hasnt changed in over half a second. It's kind of a dirty way to do it, but I guess that is what CI.MaxMeasPeriod is basically doing anyways.

I meant to post some code earlier today but I wasn't able to work on this today at work. Hopefully tomorrow.

Thanks for the reply though, two minds are always better than one.

Corey R