Is it possible to use "Delay Values" to create a frequency signal from digital "Count Edges" -task? (= are the results I'm getting correct?)

[Aleksi-]

Hello.

I have a digital encoder from which I need freaquency information (to ultimately get rpm -infromation). The problem is that this task is inside a loop with 2 other DAQmx -tasks that are using "one sample on demand"-aquisition mode and if I configure this new counter task to be a freaquency task, it only updates once in ~ second which makes the whole loop lag.

I thus created an "artificial" freaquency signal by using "Count Edges" -aquicition mode and the "Delay Values" -block so that I substract the delayed signal from original "Count Edges" -signal. There is a 0,01s delay in the loop and I figured out that if the history of the "Delay Values" -block is 100 samples I would thus get the real edge-freaquency.

I tested this configuration and the results seem to be at least really close to correct but I have no idea if this idea is in any way correct...

This explanation was probably quite confusing so please see the picture attached.

Thanks a lot in advance! 

[nathand]

Can you attach your VI, instead of an image? There's no way to tell how your DAQ Assistant blocks are configured, and since the outputs are dynamic data the wire type doesn't help either.

If I've understood correctly, essentially you are just looking at how many edges have been counted between iterations of the loop. It seems to me that you would want to use a delay of only 1, because you want to compare since the previous loop, but I haven't followed all your math through. In that case it would be better to use a shift register or feedback node instead of Delay Values (in the interest of not using Express VIs).

I don't understand the problem with using frequency measurement, though. You might need to look at how it's configured. If there's no way around the lag, you could move the frequency counting to a separate loop, and use a notifier to pass the most recent value. Again, posting your VI will make it easier to suggest a better approach. Eventually you should move away from the DAQ Assistant and use the DAQmx functions directly, they are not too hard to learn.

[Aleksi-]

First of all, thank you for quick reply. Unfortunately I don't have the acces to the vi. until tomorrow.

And yes, I think you understood correctly: essentially this arragement measures how many edges have been counted during one iteration. This is how I figured out that this could then be used as a frequency measurement:

1. From the "Edges - Delayed Edges" I get the information on how many edges have been counted during last iteration.

2. I "know" (really I don't?) that one iteration lasts ~0,01s because of the delay in the loop.

3. There is 2048 edges in one round of the encoder so I get the rpm as follows: rpm = (edges - delayed edges)/204,8*60(s)

(If I was using history size of one as you suggested it would be: rpm = (edges-delayed edges)/2048 * 60) However using history size of 10 and taking it account in the multiplication smoothens the response nicely.

But doesn't this arragement count on the fact that the vi runs smoothly and there is no additional lag?

I quess using another loop and notifiers for a dedicated freaquency measurement as you suggested could be worth trying. I just have to first learn how to use them. 

If I do use them will the main loop run smoothly and not wait for every update of the notifier? This would be essential since the freaquency output refresses only about once in a second if I use the continious aquisition mode.

[nathand]

---

Aleksi- wrote:

But doesn't this arragement count on the fact that the vi runs smoothly and there is no additional lag?

---

Yes, it does - any time you do math that assumes a particular time interval, you run the risk that the result will be incorrect if the actual time interval doesn't match the desired one. You may not care about a small amount of variation; you'll have to determine if this is a real problem for your system.

I'm not convinced that the long delay is providing any smoothing. At constant speed it may not make much difference, but during changes in speed you're not getting good data. Picture you're at 0 speed for a while, then you start to accelerate. On the 9th iteration after the acceleration starts, you'll be subtracting 0 so it will look like you're going really fast, made worse by multiplying by 10. If you want to smooth, use a running average or a filter.

---

Aleksi- wrote:

If I do use them will the main loop run smoothly and not wait for every update of the notifier? This would be essential since the freaquency output refresses only about once in a second if I use the continious aquisition mode.

---

I generally like notifiers, perhaps too much. You could equally well use a functional global variable or some other shared storage. If you use a notifier, store the previous value in a shift register and set a reasonable timeout. If the notification times out, then reuse the previous value from the shift register.

[Aleksi-]

Thanks again! I'll definetly try the notifier-solution when I get back to the drawing board tomorrow.