Frequency to RPM only working in higher frequencies

[mcgraa98]

Hi all,

I am reading the tach signal from a BLDC motor consisting of a square wave that varies in frequency with the RPM. The issue I am having may need some further explanation, but I will try my best to describe it accurately. (Using an NI-9401 module on the NI-9178 Chassis).

So far, with the configuration that I have attached, I am able to read the tach signal to obtain RPM; However, the signal seems to only be read accurately over 100Hz. I was having some issues with noise previously, until I found a task property CI.Dig.Fltr.MinPulseWidth that according to help, "specifies the minimum pulse width the filter recognizes". The 100Hz carrier frequency of the PWM signal that controls motor speed was somehow making it through the motor controller, and in adding this filter I was to eliminate the interference from this signal to obtain a reading.

I am curious if it is most likely this filter that would inhibit the ability to read the frequency of the tach signal under 100Hz. I am getting some sort of signal on the low end, because I still see a value in the RPM, but it is entirely inaccurate and it is only once I reach the 40-50% duty cycle range that the frequency is being read accurately. At the 10% duty cycle range, the RPM should roughly be 805 RPM and my signal fluctuates from 0-270 RPM. The frequency here is about 53.5 Hz and I used a multi-meter to verify that this is the signal at both the compressor and at the cDAQ terminals. I have adjusted the scaling several times to match this, and it's almost as if the signal just cant be read at that low of a frequency.

I have attached a photo showing the Read and Write RPM section of my code. If you see any stand-out issues, or suggestions it would be much appreciated. Without the filter, I cannot read the signal at all, for there is too much noise. With it, Its like my signal is dampened and I can't read it unless it is at a higher value than my PWM signal (Which is at 100Hz).

What do I do!? Hoping you guys can yet again help me get through this issue.

Thanks for all of the help and support.

[Minions]

If your filter that you are using is a high-pass filter, it should squash anything below that frequency.  Also, be aware that if your power is not isolated that it may be coupling onto your signal causing chaos with your readings as well.

[Kevin_Price]

I both see and read some possible problems:

1. Most concerning of all, you make reference to the digital filter and say, "Without the filter, I cannot read the signal at all, for there is too much noise".  If the original signal is *that* bad, I'd be wary of expecting too much magic from the digital filter. 

2. It isn't clear how you've configured the respective tasks.  I'm supposing for now that your RPM measurement is a software-timed on demand task (no call to DAQmx Timing to define a sample clock and create a task buffer).

3. If you have a digital filter set for 10 msec minimum pulse width, you shouldn't see pulses *shorter* than 10 msec, corresponding to frequencies above 100 Hz.   This should lead to the opposite of the problem you describe.  Frequencies below 100 Hz should pass while those above 100 Hz get blocked.  (Not precisely true.  There are technical details I can't consult right now but there's actually a 2:1 ratio between the shortest period that's guaranteed to pass and the longest period that's guaranteed to be rejected.  I don't recall whether specifying 10 msec puts those guarantees at 5,10 or at 10,20 msec)

4. You've decided to cancel/ignore timeout errors (-200474), probably because you were getting a lot of them.  However, you *aren't* ignoring the data that comes out with the error.  Typically you'll get 0.0 out for data when there's an error.

5. You have a moving average function, seemingly based around 100 somethings (samples maybe?).   This may help smooth over all those false 0.0 readings you get with the errors.

 6. You'll get that timeout error more when going slower.  The filter blocks high frequencies above ~100 Hz, while the 5 msec timeout you feed to DAQmx Read means that you should *expect* to timeout whenever the freq is less than about 200 Hz.  (As a first order of approximation.  There are some layers of subtleties related to quantization and driver sleep modes but the first major step is understanding the nominal size of these timing constraints.)

    So, yeah, that's a problem.  Everything happening fast enough to read within the timeout window should (nominally) be getting blocked.

7. You have a nominal loop rate of 20 Hz (due to the 50 msec timer function in the loop).  If the 100 "somethings" for your moving average are 100 samples, that gives you 5 seconds of memory in your RPM measurement.   Offhand that seems like an awful lot.

All in all, there's a lot of inter-related not-so-optimal stuff going on.  It probably developed one thing at a time where the immediate effect seemed like a helpful thing to try without realizing what the side effects might be.

You need a different approach than this combination of digital filter, short timeouts, long-memory averaging, and ignoring errors but not the corresponding data.  Obviously, getting rid of the noise would be the best thing but I'm supposing you already tried and that's why you're doing these work-arounds.

If you have to accept the presence of intrusive noise, I'd be inclined to pursue an approach based on hardware-clocked quadrature position measurement (I'm supposing the motor gives quadrature encoder output -- both A & B channels.)  You'd need to test & characterize to be sure, but in general quadrature will have greater immunity to "glitchy" electrical noise.

You could sample at, say, 1000 Hz.  Then you could read 50 samples per iteration to pace your loop at 20 Hz.  You could then take those 50 samples and the known sampling interval to do a best fit line.  The slope of that best fit line gives an average velocity over the last 50 msec.  This amount of averaging plus the lower noise sensitivity of quadrature may make you not need the moving average for computing RPM.  And you should be able to read very low speeds without getting timeouts.

You'd probably need a 3rd counter available to generate the sample clock that gets used for quadrature position measurement.  I think your chassis/module combo can provide that, but I could be wrong -- I don't know the cDAQ hardware line all that well to say for sure.

-Kevin P

[mcgraa98]

Kevin,

I appreciate your help more than you may know. As you may have surmised from my initial statements, I am fairly new to the entire LabVIEW environment (about 6 months). I started this excursion back in February as this project was handed to me by my now retired predecessor. Much of the real-world application was built by myself, and the LabVIEW portion of the build was initiated by my former colleague. As to what the thought processing was behind some of the programming, I am not entirely sure. I understand what the intention was, and I have muddled my way to a point where this RPM issue is the only portion of the program giving me issue (for now).

The error code (-200474) is being cancelled because I am also producing the PWM signal from the NI 9401 module and my program states that this resource is reserved unless I ignore the error code, or use a separate module. Maybe this is not the best way to do this, but it was the only way I found to configure that portion without issue.

I will have to touch base with one of the on-site electrical engineers to see what options I have for measuring the signals on the unit. I'll be sure to inform as to what the solution ends up being, but for now I think I will try an entirely new approach as opposed to revising the pre-existing code.

This Sub VI is a part of a much larger application, and the fact that you could identify this many issues in one "snippet" raises some concerns as to what may be inaccurate with the rest of the project. For now I will be tackling the RPM issue.

In the mean time, thanks again.

-Andrew M.