12-06-2012 06:38 PM
I am using cDAQ 9174 with a NI 9401 to measure period of an encoder. The attached vi measures period, and calculates an average value of 15 periods and writes the average to Excel so we can see the history of the motor movements. I am having a lot of trouble getting smooth data, and I see no reason why I should be getting all kinds of ups and downs in the data...the period should be very consistent, but, it is varying by as much as a few hundred per cent, so, clearly something is wrong. Our encoder is mounted on a carefully constructed bearing/axle that has less than 2/10,000 inch wobble, so, we believe that the mechanical system should be quite good, and the rpm is actually quite slow too, probably less than 100 rpm, so, the encoder is certainly not turning quickly, and neither is the axle, which is only 2mm diameter.
So, I decided to try an experiment and see what values I get for average encoder period with the motor OFF, and they are almost the same as what I get with the motor ON!!!! Is this the actual time of a WHILE loop in my VI? Is my encoder moving too slowly for the counter in the cDAQ chassis? I believe my encoder is 120 counts/revolution. See the attacahed .jpg of the two graphs. Can anyone offer some advice how to get reliable period values from this system? It is confusing me enormously. The Excel charts show the average value of period collected over time in units of seconds on the y-axis.
Thanks,
Dave
12-07-2012 03:47 PM
I assume that when the motor is OFF that the axle isn't moving at all, is this correct?
If so, it looks like you have periodic noise in your signal. Unless you can find out what is causing the noise and remedy it, the solution will likely be to add digital filtering to your inputs (it's a feature of the 9174):
I'd try to characterize what is on the line using a scope to see what you're dealing with (it looks to be ~3 kHz or so, but what is the duration of the periodic glitch?). You'll want the minimum pulse width setting to be longer than the maximum duration of the glitch but shorter than the time between glitches (or if you are running at high rpm, shorter than 1/4 of the period of your encoder signal).
Best Regards,
12-07-2012 06:23 PM
Yes, that is correct, when the motor and axle are not moving, there is still apparently some period showing up. Here is the result with a filter. I am using a very short minimum period, 6E-6, anything longer than this and no data shows up at all. The periodicity of the spikes is almost identical in both cases shown in the attached picture; data taken with the VI modified to include the suggested filter. What noise could there be? I am doing this in a room with nothing but an overhead fluorescent light, and some AC/DC power supplies to run the encoder, the PC, the cDAQ chassis.... Everything is very low power and low amperage... These spikes don't make any sense coming from an encoder which is turning fairly slowly. I believe that we tried some filtering in the past.... if there is a source of noise, then,...that is going to be very difficult to find, because, we are in a very very mild environment here to develop the code.... could the AC in the walls be causing this disturbance? This is not in an industrial setting; it is in my home workshop, and there is nothing on except power supplies for the PC, the DC motor, which is max 150mA at 24VDC, and...5V input for the encoder, all very small potatos, as I understand it. It's very quiet here.
If I turn off the DC power supplies and run the PC on the battery alone, then, I get the data shown in the second jpg, with nothing on at all, just veyr long periods, except for one phantom signal, apparently. I obviously can't take data with the Motor ON if the power supply is shut off.... is this noise going into the cDAQ or somewhere else? The cable from the encoder is shielded.
Dave
12-12-2012 01:30 PM
I'm on LV 2010 and can't open the code, but I'm having trouble making sense of most of the images of graphed data. The OFF and ON graphs have enough substantial similarity that it seems you must be capturing almost all noise and very little signal.
The final one *does* make some sense though, showing very regular 60 Hz noise on your encoder's signal line. The other graphs indicate that you normally get so much other higher freq noise that you never get a chance to see the 60 Hz noise, not to mention your actual encoder period signal which should be somewhere around 200 Hz (based on 120 cycles/rev, 100 rpm, and assuming direct drive or other 1:1 drive ratio).
My advice: keep trying to track down and eliminate these noise sources. Meanwhile, you should go ahead and set your programmable digital filter to reject any frequencies higher than 500 Hz or so. Having no data show up at all is not the bad thing you seem to think it is because what's getting through is of no use anyway. (Note that the 60 Hz can't be suppressed with the programmable digital filter because you need a cutoff that's higher than your ~200 Hz expected signal. You'll have to deal with that in the analog realm.)
Sorry, not a complete diagnostic or solution, but hopefully can help you get another step forward.
-Kevin P