Time between successive readings

[raghav06]

Hi guys,

I am working on getting angular position of two encoders separately, each with X4 encoding. I need to get the time between two consecutive measurements with high resolution relative seconds function, but I can't exactly figure out how. It would be of great help if you can kindly suggest a solution for this issue of mine. I tried getting the time of each iteration with the solution posted in another discussion in the forum, but to be more precise, I would like the time between two measurements as told above. Please help me in this regard. Thanks in advance, people! 🙂

[PalanivelThiruvenkadam]

Not able to view your code, Can you post the code in LV 2015?

[Bob_Schor]

I have some questions.  First, what is the Z pulse?  Is it a "once-per-revolution" pulse, or is it a "1/(2^n)", i.e. a "resolution" pulse?  How many Z-pulses per second do you expect when the shaft is turning at "speeds of interest"?  At what interval (or frequency) do you want to estimate the rotation speed of the shaft?  [Note I'm assuming a rotating shaft, largely based on your using an encoder, but that's a guess ...].

Suppose your Z pulses were arriving at 1000 pulses/second, and you wanted to estimate the rotation speed of the shaft and update it every second.  Rather than trying to measure the time interval between successive Z pulses (which requires timing tolerances much better than a millisecond range), you could "invert" the problem and count the number of Z pulses in a second.  You could use the DAQ clock to (pretty accurately, certainly within a microsecond or better) get you the 1 second interval, and could easily distinguish between a count of 999 and a count of 1000, with basically negligible uncertainty ... 

Bob Schor

[Kevin_Price]

Need more info.

Your code starts by using a global task -- we have no way of knowing what you've configured there.   Of particular interest: what kind of measurement?  How is sample timing set up?

Part of the configuration suggests that you're doing quadrature position measurement because you carefully define A,B terminals and quad decoding type.  However, inside the reading loop, you seem to be expecting period measurement data.  You can't do both at once with a single task.

There are other issues:

• your loops burn CPU, running as fast as possible, reading "all available" samples every iteration.  Some of those iterations, that # might be 0.
• the high res timing function you call to try to track elapsed time has *NO CORRESPONDENCE WHATSOEVER* to the data you read with your task.
• after terminating the loops, you build a 2D array out of each loop's 1D array of period data.  Do you realize the two 1D arrays might not have the same length?  Do you know what will happen when you build a 2D array out of 1D arrays of different lengths?

Items that look like a good idea to me:

• you arm-start trigger both tasks off a single common Z-index pulse.  This allows both tasks to have the same t=0 reference.
• you run the two task reading loops independently.  This is good to the two encoders to run at different pulse rates, whether due to different speeds or different resolutions. 

-Kevin P

[raghav06]

---

@Kevin_Price wrote:

Need more info.

Your code starts by using a global task -- we have no way of knowing what you've configured there.   Of particular interest: what kind of measurement?  How is sample timing set up?

Part of the configuration suggests that you're doing quadrature position measurement because you carefully define A,B terminals and quad decoding type.  However, inside the reading loop, you seem to be expecting period measurement data.  You can't do both at once with a single task.

There are other issues:

• your loops burn CPU, running as fast as possible, reading "all available" samples every iteration.  Some of those iterations, that # might be 0.
• the high res timing function you call to try to track elapsed time has *NO CORRESPONDENCE WHATSOEVER* to the data you read with your task.
• after terminating the loops, you build a 2D array out of each loop's 1D array of period data.  Do you realize the two 1D arrays might not have the same length?  Do you know what will happen when you build a 2D array out of 1D arrays of different lengths?

Items that look like a good idea to me:

• you arm-start trigger both tasks off a single common Z-index pulse.  This allows both tasks to have the same t=0 reference.
• you run the two task reading loops independently.  This is good to the two encoders to run at different pulse rates, whether due to different speeds or different resolutions. 

-Kevin P

---

Hi! Actually, the measurement is of rpm with an incremental rotary encoder. I need it very precise without loss of data and hence I didn't add a wait timer signal. So, I guess there's no way out of it. The attached VI is the actual one which I will be using mostly. The one I attached before is just my idea and wanted to see if it works. So I'll break it down for you -

1. I'm using an encoder with 360 pulses per revolution, so an accuracy of 1 deg.

2. With semi period measurement of A channel, I can get 0.5 deg precision, so 720 values which is better.

3. My idea (which might seem stupid) was that why not use X4 encoding and get the time between each pulse transmission, assuming minimal lag between hardware and software. 

And hence, the first VI trial. I understood it's quite impossible, but still wanted to ask you guys who are actual professionals if something can be done.

[raghav06]

Hi again! Sorry, I just noticed that I still had the previous period measurement steps in the program. I don't think it would be much of an issue as it just collects data and performs mathematical functions. Also, since the test would be conducted at 1000 rpm or more, the timing would be in microseconds most probably. It would be helpful if there's a way to get the timing of each pulse of the angular position. 😞

[raghav06]

Hi, the Z pulse is just to start the measurement on both encoders at the same time during gear mesh. It won't be used thereafter. I would like to actually determine the time taken for each reading of X4 encoding of angular position. I think it is highly impossible, but in case there's a way, I can get 1440 pulses for each revolution of the shaft, instead of 720 which I am getting now with semi period measurement between the pulses. 🙂 Thank you!

[raghav06]

Hi, please let me know if it works now. Thank you very much! 🙂

[cbutcher]

Just to ask another basic question that might give some helpful information when making suggestions...

You have two incremental rotary encoders, and you want the time between the latest (?) pulse from each of the encoders? Why is this? What are you trying to measure (I mean, what physically, not electrically)?

Making RPM measurements (per encoder) is quite easy if your device supports the DAQmx Counter "Angular Velocity" measurements, although there are a couple of settings (Divisor, Measurement Time) that previously were very frustrating for me on X-series. On cRIO-9045 I seem to have somehow "lucked out" and now it's much more simple.

However, it looks like your main focus is some sort of synchronization/comparison of two measurements... is this a drive train or something and you're looking at belt accuracy? (I have no idea if those words mean exactly what I think they mean, but hopefully the meaning is clear...)

[Kevin_Price]

Most of what you want to do is likely quite possible, but you need a better understanding of the distinction between signal timing measurements with a counter task, the background buffering of those measurements via the DAQmx driver, the retrieval of those measurements from the buffer via calls to DAQmx Read.vi, and the software timing of the loop iterations where you do these reads.

Semi-period measurement will likely be your best bet for both precise interval measurements and max positional resolution.  I can't look at the code now as I don't have a new enough version of LV here.

The measurement data holds the important timing information -- no need for fast loops or the High Res Rel Secs function.  Just take the semi-period and perform a cumulative summation of the interval times to get an array of "timestamps" corresponding to each edge of one channel of an encoder.   See the snippet below as an (incomplete) illustration.

What DAQ device are you using for this?  There's a particular issue that affects newer boards based on the STC3 timing chip, such as the X-series MIO boards.  With such devices, the period measurements won't start at the time of the triggering signal, they'll start at the 1st encoder edge *after* the triggering signal.  Thus the t=0 point for one encoder may not match the t=0 point for the other encoder despite the effort to properly configure the Arm Start trigger.

(Note: there's a pretty effective workaround, but it's more complicated conceptually.  I plan to followup on the idea exchange with more description when I get around to it.)

-Kevin P