Measure Speed Motor with proximity Sensor

Hi Members,


Currently, I'm working with Motor Generator speed measurement.
Just wondering if possible or not my integration system for speed measurement with proximity sensor and not use High Speed counter module spec.


FYI, generator spec is ONLY 250 RPM, max can rotate is 300 RPM,
Let say, take max RPM, so rotation of motor is 5 rotation in 1 sec.


Let say I'm using Mitsubishi Input Card QX40 which is this card response time can be set as 1ms, 5ms, 10ms OR 20ms.


Assume, I set response time is 1ms (with response frequency 1kHz).

Is it possible to measure speed of motor generator with proximity sensor? Just using QX40 input card.



My Configuration is :
1) QX40 with setting 1ms response time
2) Proximity Sensor (Inductive) distance detect 5 mm
3) Motor Generator spec 250 rpm (max 300rpm)


Is it possible to measure speed of motor generator as per above integration?

This is how NDT engineers measure shaft speed, but with a laser and reflective tape.


Either measure pulses over a fixed period of time or time between pulses.

Lots more to consider

The response time of the input module is only part of the process. There's the PLC scan time, how the PLC updates it's I/O scanning, the turn on and off times of the prox switch, and duty cycles of the target the prox switch is sensing. Generally you want a 50% duty cycle on the input signal - on half the time and off half the time.

The PLC class outline at corsairhmi.com refers to a very crude principle called the '2-5-10' rule. It refers to analog and timing resolutions. It says that 2x is the bare minimum, 5x is good, and 10x is ideal. You need to add up all the worse case delays of the measurement system and see if the PLC can hit twice the required speed. If so it should work. It may work adequately if the PLC is slower than that but it's hard to be sure without experimentation. Additions to the code and HMI communications can cause a marginal system to fail.

The other issue is how accurately you need to measure the speed and how often the speed needs to update. Time between pulses gives you the fastest update with the least steady signal. Pulses per time gives you a steadier signal with slower updates. I've used a combination solution where I count pulses for no less than a minimum time period. The time divisor is the actual measured time, not the fixed time period.

I think that what you are proposing has a good chance of working but you've got more homework to do first. Don't fall into the trap of listening to guys like me that try to make rocket science out of things if rocket science is not needed for your application.

Simpler way would be to use a Digital to Analog converter such as the Wago 857-500. Set up a scale with parameters on the analog input for a 4-20ma. You might have to tweak the scale some to get it dialed in. Just seems easier than trying to cut up the overhead.

Yes, the fundamental calculation is straightforward: (K, time ticks per minute) x (N, Number of pulses) ÷ (ΔT, Time ticks to generate those pulses, ms) => RPM.

1tick = 1ms

K = 60,000 ms/minute = 60,000 ms/minute

There are multiple threads on this on the forum.

The problem is the discrete nature both of the quantities measured, both pulses and time (1ms increments), and of the scan cycle.

If you count pulses over a fixed one-second (ΔT = 1000ms) timer cycle, then there is an alias in sampling. Say the motor is running at just under 300RPM, and there are 201ms between pulses:

• If the first pulse is detected at ET=1ms of a timer cycle, during the rest of the timer cyclethere will be four more detected at 202ms, 403ms, 604ms 805ms, and the speed calculation will be [K x N ÷ T] = [60000 x 5 ÷ 1000] = 300RPM.
• If the first pulse is detected at 199ms of the timer cycle, there will be three more detected at 400ms, 601ms, 803ms, and the speed will be [60000 x 4 ÷ 1000] = 240RPM.
• For most 1s timer cycles, the measurement will yield 300RPM, but there will be a 240RPM value every so often, the long-term average will be whatever the actual speed is, but the algorithm will never produce that value.

If you measure the time to reach a fixed number of pulses (N = 5), the there is variation in how often you get a value.

• Say you start a timer at one pulse and measure the time (T, ms) from that initial pulse until the 5th subsequent pulse.
• If the motor is running at 300RPM, you will measure around 1000 ticks, and calculate [60000 x 5 / 1000] = 300RPM
• If the motor is running at 299RPM, you will typically measure 1003 ticks, and calculate [60000 x 5 / 10003] = 299.1RPM;
  • about on out of three times, because of aliasing, you will measure 1004 ticks, and calculate [60000 x 7 / 1004] = 298.8RPM.
• But if the motor is running at 60RPM, you will typically measure 5000 ticks, and calculate 60RPM, which is great, but the value will update only every 5s.
• If we change the number of pulses, then the resolution drops again, and still it will be a long time between updates if the motor goes even slower (at one pulse, 12RPM would again update only every 5s). Maybe that is okay as that will only happen when the motor is coasting to a stop anyway.

This is nothing more than an expansion on what @Corsair has already stated. As @Corsair also notes, PLC scan time and other delays will result in noise both in the timer cycle in the first approach, and in the measured tick times in the second approach.

It's a sticky problem, and to choose an approach there needs to be a statement of desired accuracy, resolution, update rate, and range of speeds for which values are needed or not required. E.g. how many seconds of no pulses will it take before the measurement should say the speed is 0?

The QX40 comes in different versions some are high speed I believe if in the first slots of the main rack you can set interrupt to read the pulses directly so no need to worry too much about scan time, or you could use the interrupt card QD something.
To enable interrupts you use the function EI then call a subroutine for I0 (I Zero for card 0) with an IRET instruction.