Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Measuring period of 2 encoders using 2 counters

Hello to everyone!
 
I have the following problem:
I realized a code to measure the speed of 2 encoders using the 2 counters of a pci 6010 daq board (one counter for each encoder).
This code read 3600 pulses (one revolution) from each encoder and write the buffered periods of the two encoders to a measurement file.
 
I connected encoder1 to PFI 1 (CTR0 Gate) and encoder2 to PFI 4 (CTR1 Gate)
No signals are connected to CTR0 SRC and CTR1 SRC.
 
In order to validate the complete system I connected only encoder1 to both PFI1 and PFI4, so that I'm sure that both counters get the same signals in the same instant.
 
If I click the start button of the Labview code while the encoder1 speed is 0 and after that I rotate the encoder the buffered periods saved in the measurement file are the same, that is what I expected to find. See 0_rpm.lvm
 
On the contrary if the start button is clicked while the encoder1 speed is not 0 the buffered periods are significantly different and I cannot understand why. See NOT0_rpm.lvm
 
I attach also the Labview code.
 
Thanks a lot in advance,
M.G. Susy
 
Download All
0 Kudos
Message 1 of 5
(4,089 Views)
I can explain the problem, but I don't think your board provides the features you'd need to synchronize the measurements.

The two period measurement tasks run in parallel to one another, and there's no way to predict which one will arrive first at a 'DAQmx Start vi to start measuring the already-pulsing encoder.  If you look closely at the data, you'll see that each measurement in the second period column (except the very 1st one*) corresponds to the measurement 19 rows further down in the first period column.

Some boards, such as the 660x or the M-series boards, support using a digital 'arm start' trigger to sync up counter input measurement tasks.  However, I don't think yours can do that.  The best you can do is to use dataflow to force the two tasks' call to DAQmx Start to be one right after the other.

*Note: very 1st period measurement in a buffer is typically not meaningful.  It represents the somewhat random time between when the counter really got armed and when the very first edge came in.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 5
(4,083 Views)

Hello, many thanks for your reply.

I think that also this board supports digital triggering (as far as the specifications in the help file arecorrect). This is another .vi I made and has the exact same behaviuour.

The thing I really don't understand is: why when I rotate the encoder _after_ I push the start button everithing is PERFECT? As soon as I try tu start the acquisition when the encoder is rotating I obtein the errors.

This thing is driving me crazy, if you have any Idea I would really apreciate!

Bye,

M.G. Susy

0 Kudos
Message 3 of 5
(4,065 Views)
My mistake -- I thought I recognized your board # 6010, but I was wrong.  I've never used one of those "B-series" boards, but having just looked at the online help I'd have to agree that triggering should be an option.
 
That should make the app easier.  The idea will be to configure both encoder tasks to use a digital "Arm Start" trigger which will make them be sync'ed in time, provided they are both started before the trigger signal arrives.  I often like to generate the trigger signal with a digital output so my program can control the timing sequence.  I'll try to modify your post to make an example.  However, since my LabVIEW PC is far from my network PC, it may be a little while before I can examine and modify it.
 
Meanwhile, more explanation about what's happening now.  First consider the case where the encoder is constantly spinning and generating pulse edges.  Now your program starts up and one of the encoder tasks executes 'DAQmx Start.'  The counter will immediately start counting timebase cycles to measure time.  When an encoder edge comes along, the count value gets buffered, then the count resets to 0, and keeps on counting additional timebase cycles.  The next edge buffers another count value and resets count to 0, etc.  Sometime a little later, let's say 19 encoder edges later, your *other* encoder task executes 'DAQmx Start' and does the same thing.   Both will show the same measurements during the time that both are running, but the earlier task will contain a bunch of samples prior to the time the later task started.  That's why you get an offset in the data arrays.
 
Now consider the case where the encoder is stationary.  You start your program and the earlier task executes 'DAQmx Start.'  The counter immediately starts counting timebase cycles, but nothing gets buffered yet because the encoder isn't moving.  Just a little while later, the later task executes 'DAQmx Start.'  It doesn't buffer anything either.  Finally, you move the encoder to create a sequence of edges.  Since both tasks are already running and waiting for those edges, then they buffer their data in sync with one another.  All the array elements (except for the very first one) will match up.  The difference in the values of the first array elements is the time difference between when the two tasks really started.
 
If you instead program both tasks to use an "Arm Start" trigger, and you can make sure that the tasks have both started before the trigger edge happens, then your data will be sync'ed no matter whether the encoders are moving or stationary.  Even the first array element values should match.  Then you can be confident about capturing 2 different encoder signals.
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 5
(4,059 Views)
Hello Kevin
 
Now I understand why!!!
 
 
> That should make the app easier.  The idea will be to configure both encoder tasks to use a digital "Arm Start" trigger which will make them be sync'ed in time, provided they are > both started before the trigger signal arrives.  I often like to generate the trigger signal with a digital output so my program can control the timing sequence. 
> I'll try to modify your post to make an example.  However, since my LabVIEW PC is far from my network PC, it may be a little while before I can examine and modify it.
 
I would really appreciate it because I'm trying with "armstart trigger" and "star trigger" tbut without success...  the problem is always the same, so I'm missing some step.
 
Meanwhile... Thank you again!!!
 
M.G. Susy
 
 
0 Kudos
Message 5 of 5
(4,049 Views)