Recording High Resolution Angular Position w/ Encoders

[Vibes_saves_Lives]

Hello - 

I have a setup with two incremental encoders (3600ppr) wired in quadrature connected with a belt between the shafts. I want to record, in a txt/table/spreadsheet form, the angular position of each encoder simultaneously in time. From examples I have found in the forum, I have a digital read out that measures position to the necessary accuracy, but I cannot figure out how to record the data in a file that I can analyze in Excel/Matlab/LabVIEW.

The encoders are rotating at 3 rpm which results in a 720 Hz frequency of pulses, so a 10kHz sample rate should be adequate to capture position down to 0.025 degrees (1 pulse in quadrature), but I cannot figure out how to establish that rate in LabVIEW. As the block diagram shows, I have no timing block because it functions without it. Is the sample rate selectable as is? I'm sure it's not complicated, but I am struggling to figure it out. Any help/pointers/helpful links would be much appreciated.

Encoder portion of VI is attached along with front panel readouts. LabVIEW 2011

Thanks!

[Kevin_Price]

1.  When you start a task without a call to DAQmx Timing.vi, it'll work but you'll be using a software-timed on-demand sampling mode.  If you want to sample at a fixed rate, you'll need to configure a sample clock using DAQmx Timing.vi

2. Depending on what data acq hw you have, you may need to generate a signal to act as a 10 kHz sample clock.  I often would make a "dummy" AO or AI task for this purpose, and share its sample clock for my counter tasks.

3. As you proceed, you'll want to understand how to use a producer-consumer architecture so you can decouple the data acq loop from your post-processing operations like user displays and file writing.

What data acq board(s) do you have?

-Kevin P

[Vibes_saves_Lives]

Thanks for the reply Kevin.

I have attempted to wire a timing block into the block diagram, however, I didn't observe an increase in sample rate.

Additionally, I have attempted the 'dummy' AI/AO task, but what I found was that the internal AI/AO clock interferes with the other AI task in my block diagram. According to what I have read in errors that I have produced, I would need to wire those two AI/AO's in series with the same task, again no success there.

I understand there are better, perhaps more complex ways of building a block diagram for what I am trying to accomplish, but my current task is to build a VI to replace an already incredibly complicated un-troubleshootable VI. I am open to the architecture style your speaking of, but simplicity and the ability to modify are key in my current effort.

My DAQ board is a PXIe-6341 in a 1071 chassis.

For proof of concept, could you recommend a simple single encoder block diagram that captures data at 10 kHz using DAQmx? I believe if I could see what a correct timing block diagram looks like, I could easily apply it to my application. I have found several in the forums, but most use AI/AO as the task, I have not found one that uses a quadrature encoder as the task and samples at a specified rate.

Thanks for any help/tips!!

[Kevin_Price]

Another thing just occurred to me.  I kinda suspect that you've chosen your sample rate for the wrong reason.  It's a fairly common "mistake" made by people that are. more accustomed to analog acquisition.  It *appears* to me that you're aiming for at least 10x oversampling, a decent rule of thumb for analog work.  That rule is totally unnecessary for counter work.

The counter hardware will accurately track position in its count register regardless of how often (or un-often) you retrieve those counts.  You saw this already when running in a software-timed sampling mode.

With encoder measurement, I would choose a sample rate based on the needs of system dynamics analysis.  That's where the 10x or 20x rule of thumb may come into play.  In the example below, I set the default rate at 2.5 kHz just to show that you don't need 10 kHz.  You might only need about 1 kHz.

I don't have real hw, but this ran just fine with a simulated X-series device. You'll just need to change the device/channel designations.

-Kevin P

[Vibes_saves_Lives]

Hey Thanks Kevin!

I think part of my problem was not starting the encoder task before the AO task which produced an error. Now that I have that issue cleared up, back to my base question. If the encoder count regester tracks position accurately at each pulse when it receives a pulse (or count) how can I save that data over time in say TDMS/Excel/Text? Going back to your point about the sample rate, I completely agree. It makes sense to me that the sample rate does not matter for counter work until I want to know what that is over time (dynamically) and record that information. It is my understanding that once I can save data in TDMS, I can export it or convert it into a different form. Not that I want to add complexity to the mix, but I'd like to be able to trigger the recording of that encoder data at a specific position and end it after a certain position (in degrees). If you could point me in the right direction for that, I would be grateful.

Thanks for the help!

FYI - This code worked with my hardware without any issues. Thanks!

[Kevin_Price]

My main use of TDMS was back in its early days (LV 8.0 & 8.20) before support was integrated into DAQmx task config calls.  My dealings with TDMS lead me to say this: don't plan to dabble -- be prepared to make a commitment.  The same would be true for other binary formats, even moreso for many of them. 

Stuff related to triggering the logging to begin and end at certain positions is something you'd need to scheme up in your application software.  Any time you store data non-continuously, you should give some thought to how you'll delineate the data segments so you can identify and reconstruct them later.

-Kevin P

[Vibes_saves_Lives]

Kevin -

I've got a good program now where I can collect data and convert that data from a TDMS file to a CSV automatically within the VI. Also the data is triggered which works well. In my data though, I am getting zeros every so often in the encoder position measurement that skews the data set. I'm not quite sure how to solve this one. The zeros appear with any sample rate it seems. Data appears as the encoder rotates, then records a zero, then back to the correct position. Any ideas about what could be going on? I have 2 encoders and both are producing these zero values in the measurement. I thought maybe the encoder was damaged, but both can't possibly be damaged.

Also, do you have any experience with FFT analysis in LV? How about filtering? The reason I ask is, my encoders in quadrature are picking up high frequency vibrations from the drive motor. I can reduce the resolution of the encoders or filter the data and I would rather perform an FFT and filter out what I am certain is motor noise. I'd like to do an FFT vs. Time of the data if I can figure out how to do that in LV.

Thank You!

[Kevin_Price]

1. Tough to say for sure about the zeroes, except it sounds very much like an app software problem not a data acq or hardware one.   The only shot in the dark is to wonder whether you are building up a 2d array out of a bunch of 1D array reads.  If you do that without carefully ensuring that each 1D row has the same length, the process of building a 2D array will pad any shorter rows with default (0) values.

2. If you see high freq vibrations, don't filter them away and lose them.  That's important motion data!

3. Do you really want FFT vs Time, i.e., a 3D plot with a marching series of FFT slices across the time axis?   That'd be mainly be useful when a system has spectral behavior that varies significantly during transient events.

   Or do you just need the more common FFT, which gives you a 2D plot of vibration amplitude vs freq?  Time is not represented in an FFT because there's an assumption that the phenomenon (vibration) keeps repeating itself over time.

Any level of LabVIEW above Basic will have FFT-related functions (and filters).  Plan to do some leg work to understand distinctions between different FFT-related functions.  Remember that your frequency resolution (your ability to pinpoint precise frequencies) will be 1/T (where T is the total sampling time).  Be sure to collect long enough for the precision you need.

-Kevin P