Frequency measurement on a normal input

[LeonMötter]

So let begin by stating that i know that there are fast inputs which are specifically designed for these kind of problems but in this instance i could not use them and for that matter i don't think i need to.

To explain what i am doing: i have a oven with 2 internal fans that i need to check if they are rotating. If they stop rotating for some reason an alarm goes off. The way i realized this is with a inductive sensor and steel bolt in the axle. Really basic stuff. Then in my program i used the following net to count the number of rising and falling edges:

I do that for a set amount of time (for now it is set to 5 seconds) and if after that time if the counter is not zero than the axle is spinning and every thing is oke. really simple and works almost without any problems. I say almost because at one point a thought to myself, hey if i am measuring this over a set time i can calculate the speed at which the axle is rotating and use that troubleshoot performance of my machine when i need to.

What i noticed then was when i increased the output too the motor the rpm measurement went down instead of up. My first thought was well i am probably hitting the limit on what i can measure on normal input only that it was only with one of the 2 axles and even weirder is that that axle that was giving me problems started around a 40 hz signal from the sensor, while the axle without problems was running at almost 100hz from the sensor without any difficulty. So now i am really curious about what is happening here. Could there a difference in response time between inputs? Could this somehow be related to programming? Or am i just abusing the PLC to much and should not expect more?

I really want to understand what is going on here, not because i need to but because i want to. 🤔  

[Flex727]

What is your PLC scan time (SI 0)? What I/O module are you using? I presume since it is I 4, then it is one of the Snap-In modules?

Also, why are you counting both rise and fall of I 4? One can't happen without the other.

[kratmel]

Input Response Time  = 10ms typical, when used as normal digital inputs.

In your setup

1 turn Time1(sec) = 1/ Freq (Hz) = 1/40 = 0.025sec=25ms

1 turn Time2(sec)=1/100(Hz)=0.01sec=10ms

Your sensor "see" metal only for short  time during the 1 turn.

If you increase the frequency, the input does not have time to "see" a number of pulses - the sample frequency drops.

 

For test fan rotation you can use timer started by sysytem RUN bit.

Sensor from your setup must reset timer by --|P|-- .

If no timer reset  present for preset time - you set alarm by timer and clear RUN bit.

No calculation needed.

 

If you use HSI - you can use hardware calculated Frequency on the 100, 500, 1000 msec time base.

It is symple to convert this to RPM and compare with needed min value.

[Flex727]

7 minutes ago, kratmel said:

For test fan rotation you can use timer started by sysytem RUN bit.

Sensor from your setup must reset timer by --|P|-- .

If no timer reset  present for preset time - you set alarm by timer and clear RUN bit.

No calculation needed.

Here is kratmel's suggestion visualized:

This really is the best way to accomplish what you're trying to do.

[Flex727]

I should point out that the OP's main question here is why are the two different motor sensors being responded to differently by the PLC. I think a partial answer is that with a 10ms response time on the input and probably 4-10ms scan time, aliasing will play a large role in detecting the pulses accurately. I would bet if you put an oscilloscope on the two sensors you would see a small difference in the pulse width which can be magnified by the PLC response due to response time and PLC scan time interacting.

[LeonMötter]

Thanks for the answers, i have suspected that puls width could be off influence only no oscilloscope to measure with. I have thought about rewiring the plc so that i could use a high speed input to maybe get a clearer picture of the problem, but that would be a lot of work just to satisfy my curiosity. i don't think my boss would agree with that.

The reason for using both rise and fall was because i was not sure which one would work better, or phrased differently i wasn't sure if the PLC could miss a rising or falling edge. but based on your comment that is not an option. 

The PLC in question is a SM35-J-RA22 and the scan time is 1.

Also thanks for the programming suggestion, that is a nice solution. 

[Ausman]

Kratmel and Flex have answered well. 

But FYI in your knowledge seeking, I sort of do what you've done with regards to a bolt in the axle.  My methods let me easily use normal inputs for most standard motors.  The trick is that you have to ensure the sensor is on or off for 180° of rotation.  In my cases I always base my sensor position by first looking at the maximum rpm the relevant shaft is going to be doing.   It is often not acceptable to have the sensor reading the head of a bolt that is perpendicular  to the shaft eg a bolt screwed into a hub much like a locking grub screw.  This is because of the speed of the bolt head going past the sensor, and the corresponding minimal on time that the plc will not register consistently.  However, if you reposition the sensor so that it is inline with the shaft and reading the bolt thread where it enters the hub and positioned as close as possible to the shaft, the on time is vastly different and may  work ok.  eg  a 1440rpm motor equals one rev every 41.6 ms.  So if you divide that by half and definitely have the sensor on/off equally over 180°, then it will work ok.

I don't do this sensing on the motor if it is driving something via a gear train or vbelts.  I do it on the final driven shaft, (an extreme example would be the conveyor roller furthest from the drive) as this is a check that the actual process is occurring ok.  I see so many people simply checking that a contactor is ON, assuming that that then makes the check correct.  It doesn't, it only checks the motor is getting power, (sometimes not  if the read is only on a separate contact set) and is a very common failing in machine design. But for motors doing direct drive that need the check, I mostly do the sensing by machining a simple cutout into the end of the rotor, or fitting an auxiliary hub with the same sort of 180° cutout.   The sensor is then mounted to the fan housing and positioned so that it is pointing axially along the shaft with enough offset to read the 180° of metal accurately, which ensures the relative speed is very slow.

Mechanical layout and logical thinking can get you past seemingly very hard issues and use much simpler methods. 

I actually dislike "Tech for Tech's sake".

Cheers, Aus

[kratmel]

54 minutes ago, Ausman said:

I actually dislike "Tech for Tech's sake".

I would like to mention another feature of fan performance monitoring.
From time to time I service an ABB robot in which the computer is blown by two fans and the servos by four fans.
All fans have a built-in pulse speed sensor.
The fan stop error occurs only in one case - when the bearing is stuck in the fan and never when the electric motor in the fan has burned out.
This is because a fan with a burned out motor rotates in the opposite direction, and good fans do not cool the system but spin a broken fan.
This problem cannot be tracked when the robot control system is running. However, the system overheats.

I don't know about the settings of the authors' internal fans. But perhaps the different performance from the fun sensor is the result of the interaction of their airflows.

If you have two or more fans trying to work for one thread - it is possible that a faulty fan will spin and there will be no error.
However, to control the direction requires two sensors per fan, which is expensive and therefore impractical.

Therefore I will supplement Ausman ideas.

It is the sensor which reacts to a plate which is lifted by an air stream from the fan.
I met this method of fan performance control in welding equipment.
It has one useful side effect - when the phases in the network are mixed up and the motor rotates in the wrong direction - there is an "error" that prevents the network from connecting incorrectly. ONE sensor - TWO ERROR is checked!

[LeonMötter]

17 hours ago, Ausman said:

Mechanical layout and logical thinking can get you past seemingly very hard issues and use much simpler methods. 

That is one of the reasons i started this way. The first mention i got when we started to think of putting some kind of error detection on the fans was just "put an encoder on it". Sure it would would work but it will take a lot more time and money to get right. also because off the high temperatures i am always a bit worried of putting expensive parts near the oven.

17 hours ago, Ausman said:

It is often not acceptable to have the sensor reading the head of a bolt that is perpendicular  to the shaft eg a bolt screwed into a hub much like a locking grub screw.

Yesterday i took some time on the lathe and mill and i made a special measuring ring that i can clamp on the axle. this was a little bit more work than your suggestion but the result is the same. all the problems have since been gone.

 

16 hours ago, kratmel said:

I don't know about the settings of the authors' internal fans. But perhaps the different performance from the fun sensor is the result of the interaction of their airflows.

Well their airflows have some influence on each other but not much. The fans i am talking about are 1.1Kw exhaust fan and 5,5kw internal circulation fan. the exhaust fan is for gasses of the burner and that is regulated by the pressure inside the oven. We are required to keep the oven in a slight vacuum so now gasses can get into the production facility. The reason i started monitoring fan speeds was because that is a good indication of leak of a broken seal of the oven. The fan then has to spin faster to get the same pressure. The pressure regulator is not controlled by the PLC so i can not take data directly from that. 

[kratmel]

3 hours ago, LeonMötter said:

...problems have since been gone.

It is good news.

3 hours ago, LeonMötter said:

The reason i started monitoring fan speeds was because that is a good indication of leak of a broken seal of the oven.

One of possible solution is to use rotation monitoring sensor on page 92.

https://stevenengineering.com/tech_support/PDFs/45SENSOR_INDUCTIVE-PROX.pdf

But in critical safety application - safety RPM monitoring sensor, or sensor+relay must be used

https://www.ifm.com/download/files/ifm-safe-and-reliable-rotational-speed-monitoring-sensors-motion-control-GB/$file/ifm-safe-and-reliable-rotational-speed-monitoring-sensors-motion-control-GB.pdf

You can send signal from this sensor to the PLC for evaluation or directly to oven control  for alarm purpose.

[Ausman]

On 5/8/2020 at 2:10 AM, LeonMötter said:

Yesterday i took some time on the lathe and mill and i made a special measuring ring that i can clamp on the axle. this was a little bit more work than your suggestion but the result is the same. all the problems have since been gone.

Great! 

You went about it the way I have also had to do sometimes.  The beauty is it can be easily changed onto anything being replaced, rather than having to do machining on every new bit that comes along. 

I normally don't just do an "it is spinning" check, I do speed checks and reference these to pre-determined limits.  I feel sure that even though your system has something else controlling speeds, limiting parameters can be easily determined that will then allow proper alerts.

Cheers, Aus