how to measure the period of each consecutive pulse in a pulse train?

[feilong]

Hello all,

   I am trying to measure every pulse period in a infinite pulse train. the pulse is actually from a encoder(360 pulse per rev) connected to a varing speed shaft. The mean speed is around 6000 rpm at the highest point, and it has periodic variation, this is why I want to measure the instantaneous speed.

   I tried to use A signal of encoder (360 pulse per rev) to connect to CI Period measurement terminal and read 360 sample at a time. but it seems more than half of pulse reading are missing, which looks like that the read vi need some time to finish the measurement of every pulse before it can handle next one, cause it miss some pulse.  The A signal I injected is around 10 KHz. Does my PCI-MIO-16E-4 or DAQ 6036 capable to handle this task?

thanks

Feilong

[Conseils]

In theory you have a mean frequency of have about 36KHz coming from the transducer at maximum rate and probably around 6KHz at the lower end of your range.

My actual guess is that you have a number of problems rather than one. At the the higher rates the wiring tends to become critical and the transducer possibly doesn't support this rate. I would also hazard that it won't live long either at those speeds.

At the lower end of your speed range you should certainly be OK with the PCI-MIO-16E-4 probably also up to the higher range, but watch out for the wiring even so; as if the edges are not clear you won't trigger properly. The DMA transfer would probably prefer a block size somewhat larger and I would think that 1440 or 2880 pulse transfer blocks would be a lot better! A lot of this will be determined by the rate at which the system can transfer over the DMA which can be limited somewhat by the PC performance and total DMA capactitys.

You can certainly read in a continous pulse train and not loose data.

The NI DAQCard-6036E (for PCMCIA) I don't believe it will do it at all directly.

You might also check out the following thread: - RPM as a Function of Crank Angle (optical encoder - counters). This is by MilqMan and Kevin Price, Milqman was helping you previously with your problem but you didn't seem to get what you needed, this will put you back on the right track.

You might also check out the examples that are bundled. A keyword might be 'Meas Pulse Width-Buffered-Cont.vi'

I would suggest that it's highly unlikely that you need 360 pulses per revolution and your life will be a lot simpler if you consider exactly what it is you are trying to achieve.

You might also consider adding some more stars for Kevin, his answers are just as usefull to you.

[feilong]

Hi Conseils,

   Thanks for your reply. I took a look on that discussion thread and started to study the "continously semi period buffered measurement.vi". I set a signal generator which gives 7 pulses once you press its trigger button to verify if that code could pick up all the resault. The frequency is set to 3KHZ.

  I also modified that vi a little bit to explicitly set DMA transfer and changed it to finite sample mode with 6 samples at a vi run.

  The min T value I input was 0.000028 s and max is 0.00042 s, which gives a engine rpm range of 400 rpm to 6000 rpm at 360 pulse per rev.

  And I input 4 into "sample to read" control.

  When I run the vi, after have signal generator output pulses, there's error:

 Error -200278 occurred at DAQmx Read (Counter 1D DBL 1Chan NSamp).vi:1

 Possible reason(s):

Attempted to read a sample beyond the final sample acquired. The acquisition has stopped, therefore the sample specified by the combination of position and offset will never be available.

Specify a position and offset which selects a sample up to, but not beyond, the final sample acquired. The final sample acquired can be determined by querying the total samples acquired after an acquisition has stopped.

Attempted to Read Sample: 6

Property: RelativeTo Corresponding Value: Current Read Position

Property: Offset Corresponding Value:

    It looks like the sampling procedure stops before the read.vi get enough (was 4 in this case) sample. But the sample I injected was 7 in total and the finite sample property was set to 6, which should satisfy the property of number of sample to read in read.vi.

    Could you please tell me where I am going wrong?

Many Thanks

Feilong

[Conseils]

I don't understand why you went to the trouble of changing a well proven VI thus introducing more possible problems.

You may well have a software issue and a hardware issue.

I think that you may be creating too much complexity and not giving yourself a stable base to work from. I suggested the sample VI as you could seperately test the hardware and discover the true source of your problems. As the suggested sample software is well understood by a lot of people on the forums and at NI.

I also seem to recall that the first pulse or so in a series can get lost, as you are looking at a continous aquitision; so normally the first couple of lost pulses can be ignored.

The easiest way to test your system is to set a frequency say 2.4Khz (400 R.P.M.) then (by hand if necessary) see if you can follow a slow frequency sweep by the calculating the mean frequency (speed) with the software.

What version of LabVIEW are you using?

[BillMe]

I found LabVIEW FPGA a killer option for these kind of measurements. Five mins to code, 10 to compile...bam, you're done.

Bill

[MickeyD]

Hi Feilong,

The 200278 error usually occurs because your counter is set to finite samples.  Conseils' idea to see if the example worked "as is"  is an excellent suggestion.  This will allow you to identify where the trouble is really occuring.  I will take a look at that example and see if I can understand the reason for the changes you made.  The one thing I wanted to check are both what version of LabVIEW you are using and what version of DAQmx you are using. 

You also might want to post the block diagram of your changed code, so we have a good way to look at what you are changing.  Get back to use with some information about that and hopefully we can get this all resolved.  Seems like you have some setting slightly off.  As for the original problem of missing some of you pulses that sounds much more like a noise issue, but we can see how this program reads when we get going and try and isolate future problems from there.

Have a great day,

Michael D
Applications Engineering
National Instruments