Encoder Z Pulse Counter input measure RPM

[Lazer723]

I have an PXIe-6341 DAQ card in a PXIe-1082 chassis. I have an RLS ABZ encoder which I would like to use to obtain RPM by counting the Z pulses.

I have wired the Z pulse into a counter in the 6341.

I have used the CI Period NI DAQmx function and taken 1/T to get frequency (using CI Freq seems to gives terrible results)

which works except I am getting large spikes in the data. The spikes are random and are sometimes within the range of possible values which makes a simple cut off filter not possible. I have tried a median filter but to no avail as the spikes can last for about 3 or 4 samples.

I would like to understand why these spikes happen in the first place. I am going to use this as the feedback for a PID controller so the spikes will be very intrusive.

Any help would be greatly appreciated.

 

 

[Kevin_Price]

I've run into this kind of thing before and it can get pretty difficult to solve.  You're probably getting some kind of noise "glitch" coupled in with your encoder signal which can occasionally look like a legit digital transition, leading to incorrect period measurements.

I see you've already added digital filtering to your task, but it didn't fully solve your problem.  You could stand to set a much longer minimum pulse width and probably remove the anomaly around 8500 RPM, but I wouldn't count on being able to suppress the two anomalies at ~5500 RPM while allowing the normal ~5200 RPM periods.

Eventually, you're going to find that you need to fight this noise at its source.  And it may not be trivial to identify that source.  And after identification, suppression isn't necessarily easy either.  Things like switching power supplies and brush DC motors tend to emit a good bit of high frequency noise that can be hard to suppress.

You'll want to take a good hard look at your grounding strategy, proximity of your encoder signal wires to other current-carrying wires, the degree to which your encoder cable is vulnerable to noise (for example, is there shielding?  is the shield grounded at only one end?), and more.

Sorry, no definite answer.  Sometimes noise is just difficult.

-Kevin P

[Lazer723]

Thank you Kevin for your reply.

I'm a bit confused as well. The thing is is that I can use the CI Angular Encoder Task to log the angular position with the Z reset enabled and it works flawlessly even at very high RPMs. How come this is possible and yet the Z pulse in isolation is causing issues.

What's also interesting is that it gets even worse If I run a wire from the Zpulse terminal in the 6341 to another counter in the same 6341:

I am considering some kind of case structure+ shift registers with a conditional output to only allow values which are within +-200 RPM of the previous accepted value. 

[Kevin_Price]

When you use the quadrature-based encoder measurement modes, a digital glitch will often have no net effect.  During the very brief time the signal transitions to the wrong state and then back to the right one, the count register briefly increments or decrements to be off by 1 and then goes immediately back to the correct count again.   That's one of the advantages of using quadrature.

So with that in mind, maybe you could consider calculating RPM from a quadrature position task.  At present, you're somewhere in the neighborhood of 6000 RPM.  That's 100 revs/sec and thus 100 Hz sampling when you measure periods of the Z-index signal.

You could instead configure a 2nd counter to pulse at 100 Hz and use it as a precise sample clock for your position task.  You'll likely get more quantization error, but it may still be "small enough".   You can be off by 1 count out of 1 rev worth of quadrature counts.  For example suppose your encoder has 256 cycles each for A and B (so it can resolve 1024 quadrature positions per rev).  Your quantization error would be 1 part in 1024 or ~0.1%

-Kevin P

[Lazer723 · Accepted solution]

Just for anyone else that might have this problem with the Zpulse spuriously triggering.

It turned out to be an electrical issue, I put a 120 Ohm resistor across the Z input to the 6341 counter and GND, thus a proper high impedance termination. This worked incredibly well to remove random triggering.