How do I adapt this example to count ticks/unit time?

[dav2010]

I found the attached example in Labview 2012, for counting ticks of an encoder wheel.  I can easily count ticks with this vi and my encoder wheel hardware.

I would like to be able to count ticks in a fixed time interval, and return a value of ticks/ms etc.  I would like to do this over and over again in WHILE loop structure.

How do I modify this example to count only for a fixed time interval, e.g. 50ms, output the number of counts, and then start over from zero again?

Alternatively, I could fix the number of ticks, and measure the time that it takes to count, e.g. count to 100 ticks, and tell me the time it took to get to 100 ticks.  Either way is acceptable for my application.  Both give me "ticks/time"

Can someone suggest an architecture to do this?  I'm a bit stuck on how to start.  I was looking at the timed loop structure, but, I can't figure out how the counter would reset to zero...it seems like it would add counts with successive iterations.

I am using cDAQ9174 and NI9401 module.

Thanks,

Dave

[dav2010]

I am trying to add a timing behavior to the example, so that the WHILE loop will stop executing after a chosen time interval, called the LOOP TIME SET, which is just a WAIT function that sends the boolean to stop the loop.  The loop stops as expected based on the value selected for the WAIT function.

However,...the tick count no longer displays on the front panel.

How did adding the boolean function to the WHILE loop kill the counter???  If you compare the attached example.vi to the forum_april_12.vi, you will see the only difference is the WAIT function and boolean structure in the WHILE loop.

Really appreciate your keen eye to this.!

Thanks,

Dave

[Kevin_Price]

Between this and a couple other related threads you've got on this issue, I decided to whip up a simple example.

I got a few spare minutes at lunch and made it just a little less simple.   First here's the snippet you can drop

into an empty LV block diagram (should work for any version 2010 or later):

Comments:

1. To track ticks per unit time, the natural counter mode to use is frequency measurement.  It's designed to do

that.  I almost always end up preferring the 1 Counter mode over the 2 Counter modes.

2. The lower half of the code is the simple part, the upper part is what I added when I had a few unexpected

spare minutes.

3. The timed loop will try to execute once every 100 msec (or whatever interval you choose).  Each time it

executes, this code reads all available samples from the data acq task.  The way the tasks work, each

time you read more "available" samples, it picks up from where it left off.  This makes it easy to make sure

you are collecting all the data while neither missing any nor reading the same data over again.

4. I calculate a mean value of frequency from that subset of samples and add it to a live chart.

5. Here's where the less simple stuff comes in.  The essence of it is that the upper shift registers and

For loop are used to keep track of cumulative info such as total ticks and total time since start of task.

I then calculate an overall mean and add that to the same chart too.

6. It seemed to test ok with a simulated cDAQ device (technically, the simulated device returned an array

full of 0 values for freq so I had to add a constant and a random offset to them to make realistic #'s) so it

ought to run ok for you too.  

Good luck with the rest!

-Kevin P

[dav2010]

Kevin,

Thanks an awful lot for the help.  By the way, I"m using LV2012.  I hope I can make this thing work.  Can you do me one favor...I am still quite junior at LV programming, and I don't recognize some of the functions you have included.

1.) You have the same function used 4 times inside the big WHILE loop, including one in the small loop, a box with three boxes inside and + or x signs.. Is that "compound arithmetic" function?

1b.)  What is the function that is wired into the "AVG FREQ" indicator?  Is that BUNDLE from the CLUSTER pallette?

2.) Is there any reason that this code cannot be put into a producer/consumer loop so that I can actually read two encoders simultaneously and compare the values, e.g. frequency or ticks/time etc?  Is there a better approach to reading two encoders simultaneously than the producer/consumer architecture?

I am anxious to try this out!

THANK YOU!

Dave

[Kevin_Price]

Dave,

A few brief answers:

1a) Yep, those are "compound arithmetic".  I've tended to prefer them to the standard +-*/ operators because

they can be used when I have more (or less!) than 2 values to combine, and because they can prevent wire

crossings on subtractions and divisions.   I prefer it for Booleans too.

1b) Yep, that's a "bundle" node.  The context help for the chart shows that you need to bundle values to make

multiple plots rather than adding multiple points to a single plot.

2.  No special reason you couldn't put this into a producer consumer architecture.   Just watch out for how

you split it up.  Just be aware that if you make independent producer loops for each encoder, you might be

in for some extra work.  Here's why:

   Valid comparisons will probably need to be sync'ed so you know the values correspond to the same point

in time.  On the other hand however, one of the normal benefits of producer-consumer is that it frees your

acquisition and processing from needing to be sync'ed. 

   I would recommend a single producer loop that reads from both encoders.  To pass them to the consumer,

I would bundle the 2 arrays into a cluster, and write the cluster to a shared queue.   The consumer can

read from the queue and then handle all the other processing.

-Kevin P

[dav2010]

Hi Kevin,

I got the vi working, but, there is one weird aspect of it.  I am seeing these phantom signals.  Here are three samples of data collected varying the averaging period from 50ms to 1000 ms.  The rate the encoder is moving is about 1 revolution/second, not super fast by any means.  Notice that the phantom signals can be very large or very small

Phantom1 is 1000 ms period.

Phantom 2 is 100 ms period (it's hard to see on the picture, the actual frequency measurement is about 120Hz, as seen in the Excel file data)  The spike to 450,000HZ makes the rest of the data look like ZERO, but, it is actually similar to the others, since all three were collected at the same motor speed.

Phantom 3 is at 50 ms period.

The frequency is about 120 Hz.  This encoder has 120 ticks/revolution, so 120Hz, is one rev/second.

Is there a filter that can be added to eliminate these signals.  They are positively definitely and for certain, NOT real.  My system is a simple belt driven encoder from a DC motor at fixed speed for all three collections here...the spikes up and down are impossible.

I also attached my vi, in case you want to see if I ruined anything adding the WRITE TO SPREADSHEET function.  I will post in the next one..apparently there is  a limit of 3 attachments.

Thanks,

Dave

[dav2010]

My vi, as mentioned above.

[SunainaK]

Hi dav2010,

It looks like you were having this problem previously and found the solution:

http://forums.ni.com/t5/Counter-Timer/Why-am-I-getting-phantom-signals-with-the-counter/td-p/1900431

[dav2010]

Hello Sunaina K.,

No, that is not correct.  The problem I was having earlier was associated with measuring PERIOD, not frequency.  The phantom period measurements were resovled by applying a digital filter, however, this fix does not work with the frequency, except at extremely low and unusable frequencies.  Look carefully at the earlier posts and you will see they deal with PERIOD.  The more recent post deals with FREQUENCY.

David

[dav2010]

sample