Synchronizing AI, DI and Counter i/p on two DAQ boards

[Neil_S.]

UBAP,

When doing a frequency measurment the DAQ board will buffer a sample for each period of the pulse train generated by the encoder.  The error you get indicates that the pulses were coming to fast to be buffered into the computer memory.  The DAQ card has a limited 2 sample fifo for the counters and can overflow if the card detects several pulses in quick succession.  I can imagine several reasons for this behavior.

First,  when you say the motor is running at 2 rpm are you saying that the motor only turns twice in a minutes time.  This seems like an obvious question but I just want to make sure this is not in thousands of rpm.  If the motor speeds get too high the counter fifo will overflow.

Second, make sure the pulse train being sent to the card is clean.  If their is ringing or other defects in the signal it can cause the counter to detect several pulses successively.  This can be caused by noise, incorrect impedance matching, or other issues.

Would it be possible to attach a scope to the output of the encoder to see how the signal looks?

Regards,

Neil S.
Applications Engineer
National Instruments

[UBAP]

Thanks for the continued support Neil,
Before going into the waveforms, here is some info that I think, might be useful in suggesting me the best solution.

1. I get two pulses per revolution from my encoder.
2. I am using a 2.40 GHz, Pentium 4 CPU that has 512 MB of RAM.
3. with NI-PCI 6221 installed on it.
   

Attachments:

• pic1: This is the code. [I used the example code "Meas Dig Frequency-Low Freq1 Ctr.vi ]. I verified the waveform in an oscilloscope, the corresponding rotational speed it shows is correct.
• pic2: This is the waveform corresponding to speed shown in pic1 [17 rpm]
  
• pic3: This picture shows the correct speed displayed when I increase the speed [27 rpm]
  
• pic4: The corresponding waveform for pic3.
• pic5: and just when it appears everything is going alright...like in a Hollywood thriller movie , It displays garbage all of a sudden...
• pic6: The error it displays immediately after that.
  

Sometimes I see the error Data was overwritten before it could be read by the system. If data transfer mechanism is Interrupts, try using DMA, Otherwise divide the input signal before taking the measurement.

• I have to include this code in another multi channel code which does...
  

1. Four analog channels,
   
2. Reads the encoder speed [the above program]
3. Gives a PWM signal to control the speed.
   

So,
Here is my questions:

1. How do I overcome the error showed in Pic6 and/or the error that I wrote in Bold.

Message Edited by UBAP on 03-06-2007 09:31 PM

[UBAP]

Please see the rest of the three files that I was unable to attach in the previous post.

Thanx again.

[Neil_S.]

UBAP,

I see a few issues with your application.  First you specify a minimum frequency of ~1.19 Hz, however, since you are measuring rotational speeds of < 20 RPM your pulse train will drop well below that value frequency = RPM / 30.  Even at 20 RPM the frequency is 0.667 Hz.  The second thing that I notice is that your voltage plot is sampling the waveform at a very slow rate.  As a result you almost miss the pulses completely (they only show a magnitude of <0.4 volts.  The behavior you are seeing sounds like very high frequency ringing that you will not be able to see unless you sample a whole lot faster > 200 kS/s or so.  You may even need to sample faster to see the ringing.

Your programming overall looks correct.  I am 95% sure that it is the external signal that is causing the problem.  Since the motor is moving so slowly, it is possible to use internal digital filtering available using the DAQmx driver.  To enable digital filtering place a DAQmx channel property node, right click and select Properties >> Counter Input >> Frequency >> Digital Filter >> Enable.  Right click again and click Change All To Write.  Right Click a third time and select Add Element.  Right click on the second element and select Properties >> Counter Input >> Frequency >> Digital Filter >> Minimum Pulse Width.  Set Enable to true, and set the minimum pulse width to 2.55 ms (the longest available filter setting).  You can read more about digital filtering in the M Series User Manual page 7-32 available at:

https://www.ni.com/docs/en-US/bundle/pci-pcie-pxi-pxie-usb-62xx-features/resource/m-series-user-manu...

Let me know if this does not fix the problem.

Regards,

Neil S.
Applications Engineer
National Instruments

[UBAP]

Thank you Neil.
Your suggestions did help but did not solve the problem completely.

To summarize, here are your suggestions for my application:

• Decrease the minimum frequency.
• Increase the sampling rate.
• using external digital filtering.

These are my observations/notes.

1. Minimum Freq: Decreasing the minimum frequency has helped a lot. I do not believe I overlooked that. I've set the minimum frequency to 0.15Hz (4.5 Rpm). It is not returning garbage that often untill speeds of upto 23 Rpm (0.766Hz).
   
2. Sampling Rate: How do I increase this? Here for my application, I am uisng "Implicit" timing. Is it applicable for my application?
3. Using External Digital Filtering: I liked your description of creating the channel node property !! Thank you. I did that. But I didnt know where to put it !! I tried putting it at different places, after the start task, in the loop, and also finally "before" the start task and I got different errors and the problem (showing up garbage) did not get solved.

Now the problem that still remains is, it returns garbage values when I go to speeds of 27-28 Rpm. It runs fine until 25 Rpm. [it returns garbage at speeds 25RPM also, but less frequently]


Please advise.
Again, Thanks a lot for the continued support...
      

[Neil_S.]

UBAP,

I am glad that decreasing the minimum frequency has helped some.  It may be that the digital filter will not work in this situation but it was worth a shot.  You should enable the digital filter before starting the task.

As far as the sampling rate is concerned, I guess I was not very clear about what I meant.  In a previous post I suggested connecting a scope to the output of your encoder to see if there was any ringing or other defects in the signal that could be causing the issue.  You returned a scope plot of the signal but the sampling rate of the scope plot did not seem to be high enough to even show the defects.  In addition, it looked as if the pulses were not even high enough to cause the counter to register the pulse which may also be a problem.

Do you have a scope that could probe the output of the encoder at a much higher rate?  I suspect it is this signal quality that is causing the weird behavior.

Regards,

Neil S.
Applications Engineer
National Instruments