Puzzling Phenomena at a special speed

We have an inductive sensor mounted in front of a rotating pulley, which has one small steel part rising close to the sensor.
The sensor is wired to a digital input on a plc, which is checking if the pulley is rotating or not, using two timers (one for ON detection, the other for OFF). The logic is executed at a fixed scan cycle of 100 ms.

Now the Puzzling Phenomena is happening only at a production speed of 80%. The plc is seeing the sensor input as ZERO! Below this speed, and above this speed, all is OK and normal!!
Can anyone explain what is happening here?...

Capacitance?

I've seen similar in the past with crappy cables on high frequency encoder signals... at a certain motor speed we only had DC in the lines.

I do think it is weird that it is only that particular speed/frequency.

Somehow your pulley speed lines up with the code execution (0.1s) in such a way that the sensor input is never triggering the timers.


Just have one timer that resets on a rising edge of the sensor input. If the timer completes, the pulley isn't moving. Of course, the timer preset needs to be high enough that a really slow speed isn't registered as a standstill.


If it's because the sensor input isn't even registered, you need to look at the sensor and/or input card. Does sound weird that it works at higher speeds, since input filtering would simply stop the signal from being registered from a certain speed and higher.

Do you have a 50Hz notch filter on your input card, and would 50Hz be roughly 80% of 60Hz?

OR,

are you sure the speed is correct when you go over 80%?

Kataeb said:

We have an inductive sensor mounted in front of a rotating pulley, which has one small steel part rising close to the sensor.
The sensor is wired to a digital input on a plc, which is checking if the pulley is rotating or not, using two timers (one for ON detection, the other for OFF). The logic is executed at a fixed scan cycle of 100 ms.

Now the Puzzling Phenomena is happening only at a production speed of 80%. The plc is seeing the sensor input as ZERO! Below this speed, and above this speed, all is OK and normal!!
Can anyone explain what is happening here?...

Click to expand...

It would help if you tell us what PLC you are using, what I/O modules, how they are connected to the PLC etc. Also what speed is the pulley rotating, and how wide is the part of the pulley the sensor is detecting. From that we can get an idea of the pulse widths involved.

Without that information we are just guessing, but I would imagine that your inputs are updated once per PLC program scan, so at a particular speed those inputs are always going to be the same level, and the PLC does not see them going on and off.

For effective capturing of the ON and OFF states of an input waveform, the PLC needs to update the input values at least twice the rate of the shortest part of the pulse

Look up Nyquist Theorem, it should help explain.

You havent shown us your code, but the two-timers program for on and off respectively sounds to me to be wrong way to do it.

For the function of detecting rotation/no rotation of the belt pulley, you shall look at the rising and/or falling edge of the sensor signal. And this should be done at the fastest cyclical rate possible (not at a fixed scan of 100 ms).
You can set a "belt is rotating" bit upon any edge detected. And reset the "belt is rotating" bit when no edge is detected plus some time.

edit: This can still fail if the prox and tab are designed wrongly. You have to find out what is the shortes pulse and pause that the PLC input can detect. That depends on the propagation deley of the sensor, the propagation delay of the PLC input, and the PLC scan. Say it is 5ms + 5 ms + 5 ms, then make sure that you have pulse and pause periods longer than 20 ms.

Is your pulley rotating at a multiple of 750 rpm when it is at 100%? 80% of 750rpm is 600 rpm. 600 rpm = 10 rev/sec = 1 rev / tenth second = 1 rev / 100 ms. At this rate, the pulley will be in the same position when the PLC logic uses the input. It will always be ON, or OFF.

To illustrate the unwanted synchronisation:

https://www.youtube.com/watch?v=yr3ngmRuGUc

CommissioningMan said:

To illustrate the unwanted synchronisation:

https://www.youtube.com/watch?v=yr3ngmRuGUc

Click to expand...

That's a good one, and a good example for what is probably happening here.