calculating rpm off pulses from a High-Speed Input

Unitronics Samba plc

I am working on a system that uses the High Speed input on a plc to calculate the rpm of a shaft. It is having issues with accuracy and I am reaching out for advice to see if there is a better way to do it.

The machine is a shavings mill. A conveyor feeds chunks of wood and lumber into the mill. The mill is engine driven, but the conveyor has a motor with a VFD so we can vary the speed. The goal is to get maximum product so it is set up so that the speed of the conveyor will adjust according to the speed of the mill. So it will automatically slow down the feed if the mill is getting overloaded or slowing down for any reason.

But the issue if the accuracy of the RPM. Due to the application, we need constant live rpm readout so the conveyor can quickly respond.

There is a prox sensor detecting targets on the mill shaft.

Currently the High Speed Input is set up as Frequency Measurement and returns a value of pulses per second. The pulses per second is multiplied by 60 and that number is divided by the number of targets on the shaft, which results in RPM, but it tends to jump around alot and is not consistent.

Is that the best way to calculate RPM of a high speed input or would you recommend a better method for this application?

How many pulses/second are you getting now? One issue with using the built-in "rate" counter is that if the pulses are relatively slow, if a particular pulse ends up on one second's "scan" vs the next, the percent difference can be huge.

If the rate is relatively slow, you COULD write your own logic to calculate the time between pulses, although most sambas have a scan time of around 2-3ms so that won't be perfect accuracy either, but may be better.

If you keep using the built-in "rate" counter, you can get improved accuracy by scanning less often, say once every 10 seconds, at the cost of a much slower response time.

And worst case you can get a dedicated tachometer with a 4-20mA output.

i do it exactly as you described with a Micrologix 1400 HSC if i dont have an encoder in the system to calculate RPM off of. What Hz is the prox? If your HSC input can handle more pulses give it as many as possible to base the calculated RPM off of. When i first did this setup i would get what youre describing, jumpy RPM reading, the higher Hz sensor and then more teeth on the pickup wheel solved the problem.

rupej said:

How many pulses/second are you getting now?

Click to expand...

JZerb said:

What Hz is the prox? If your HSC input can handle more pulses give it as many as possible to base the calculated RPM off of. When i first did this setup i would get what youre describing, jumpy RPM reading, the higher Hz sensor and then more teeth on the pickup wheel solved the problem.

Click to expand...

The mill speed is around 1400 rpm. For a while we had up to 3 targets on the shaft, that was working somewhat. Then the customer moved the sensor to a different place where he was getting 21 pulses per revolution. That worked for awhile but now it has started acting up again.

the sensor is a Schneider XS508B1PBL2. rated at 5000hz.

Any reason that shouldn't work?

lesmar96 said:

The mill speed is around 1400 rpm. For a while we had up to 3 targets on the shaft, that was working somewhat. Then the customer moved the sensor to a different place where he was getting 21 pulses per revolution. That worked for awhile but now it has started acting up again.

the sensor is a Schneider XS508B1PBL2. rated at 5000hz.

Any reason that shouldn't work?

Click to expand...

If the sensor has been moved, it could be a problem for the sensor sensing all the teeth due to slightly different distances/orientation. The sensors I've been working on has low tolerances but I haven't used this one in particular.

Also, the new teeth, 21 per revolution, do they have the same size as the old ones? Had that happen once, a company disassembled a turbine, and the a tooth was missing during reassembly. They made a new one on the spot but it was smaller. At higher speeds it would drop out.

lesmar96 said:

The mill speed is around 1400 rpm. For a while we had up to 3 targets on the shaft, that was working somewhat. Then the customer moved the sensor to a different place where he was getting 21 pulses per revolution. That worked for awhile but now it has started acting up again.

the sensor is a Schneider XS508B1PBL2. rated at 5000hz.

Any reason that shouldn't work?

Click to expand...

what is the high speed input capable of reading kHz wise on the PLC youre using?

The spec sheet says with a 10m cable length, it is capable of up to 30Khz. This cable length is definitely under 10m

Then the customer moved the sensor to a different place where he was getting 21 pulses per revolution. That worked for awhile but now it has started acting up again.

Click to expand...

That suggests that the orientation of the prox to the targets has changed.

Steve Bailey said:

That suggests that the orientation of the prox to the targets has changed.

Click to expand...

That is kinda what I am thinking too

Check the gap between the prox and the target?

And, I know of at least one prox application where if 'it doesn't read right'
try turning the prox ninety degrees. I believe that prox had a little notch
on it that needed to be properly oriented to the teeth.
Poet.

lesmar96 said:

The spec sheet says with a 10m cable length, it is capable of up to 30Khz. This cable length is definitely under 10m

Click to expand...

it seems like the system woked previously so i agree with others that in moving the sensor the customer messed something up for it reading properly. 21ppr doesnt seem right to me at 1,400rpm.

1,400rpm /60 = 23.3 revs per second
A pickup that has 3 teeth on it should then produce 23.3 x 3 =69.9 pulses per second i would think.

JZerb said:

it seems like the system woked previously so i agree with others that in moving the sensor the customer messed something up for it reading properly. 21ppr doesnt seem right to me at 1,400rpm.

1,400rpm /60 = 23.3 revs per second
A pickup that has 3 teeth on it should then produce 23.3 x 3 =69.9 pulses per second i would think.

Click to expand...

I'm sorry, I must not have been clear. Where the sensor is currently mounted, there are 21 "teeth" on the pickup. I need to verify that we are getting an actual 21 pulses per revolution feedback.

Having the prox too close to the teeth can be as bad as too far away. Too far away and the duration of the ON signal isn't long enough to be detected. Too close and the duration of the OFF signal isn't long enough to be detected. The HSC counts transitions.

lesmar96 said:

I'm sorry, I must not have been clear. Where the sensor is currently mounted, there are 21 "teeth" on the pickup. I need to verify that we are getting an actual 21 pulses per revolution feedback.

Click to expand...

i assume by verifying you would just spin the shaft slowly and make sure the the prox 'sees' the 21 teeth. Which is a good start but it may be beneficial for you to run it at speed, 1,400rpm and stop it at a set time, say ten seconds. then put a counter in your PLC to test and see how many pulses it has caught in the ten second time frame. should be 4,9000 if its picking up each tooth properly at speed.

lesmar96 said:

I'm sorry, I must not have been clear. Where the sensor is currently mounted, there are 21 "teeth" on the pickup. I need to verify that we are getting an actual 21 pulses per revolution feedback.

Click to expand...

My thoughts:


First, I second (...) what Steve Bailey said about being too close/far.


In addition,

At 1400 RPM and 21 teeth per revolution we're talking about nearly 500 signals per second. Double that because you can only count rising edges if you can the falling edges?... so at 1000Hz your sensor might not cut it, DEPENDING ON TOOTH GEOMETRY.


Consider the following cases, where ^^^^ is the raised part of the tooth and ___ is the low ("off") space between teeth:



Case 1:
____^^^^____^^^^____


Case 2:
_____^^______^^_____


Obviously case 2 is more challenging for the sensor to pick up and requires higher frequency capability?

Edit:
Here is a fairly random image to better illustrate the (possible) issue - with the actual tooth only making a small part of the pitch between teeth.