Allen Bradley programming support

Join Date
May 2010
Location
Vasai-E, Maharashtra
Posts
27
Hi Friends.
I am just learning ladder programming for Micrologix 1400 and after a deep search I could not a block to calculate RPM through proximity input. I tried arithmatics but I got stuck at 1 point that when I try to divide 60000 by a duration between 2 pulses to calculate RPM then my result overflows even my destination is float type and thereby PLC goes in fault mode. Can somebody help me out in this?
Or I shall be highly obliged if somebody sends me sample program for RPM.
Regards
Sandeep R. Mittal
[email protected]
 
Last edited:
1. Measure proximity pulses over some time period (for example, maybe 2 seconds).
2. Divide Revolutions per 2 seconds by 2 to get Revolutions per Second.
3. Multiply by 60 seconds/minute to get Revolutions per Minute.

3A. An alternative (if your measuring time period is 2 seconds) is to simply multiply proximity counts by 30 to get RPM.
 
Post your code, or at least describe your code step-by-step so others can see what you are trying to do.
All supporters,
Pls see,
calculating pulses for 2 sec or 5 sec or 10 sec is not going to work if I want prepare a logic for 5 to 500 RPM range. So what I have done i tell you. Mr. Glenn specially for you as you have asked for my steps.
1. I calculate the duration between 2 pulses. For exmple duration measured is 6 Sec. My timer base is 0.01 so my accumulated integer value comes as 600.
2. Now I divide 6000 (which is an integer constant) by this duration (which is 600 measured in step 1)
3. This should give me result as 10. This means 10 RPM.
4. Now the problem is as soon as I run my program and start giving pulses, PLC goes in fault mode.
5. I checked the error, it says result of that division block over flows.
6. I tried with result data type as integer and float both. But nothing worked. How can i avoid this fault.
7. If this is solved, then my logic will be working.
Thanks all of you.
Sandeep R. Mittal
 
It sound like when the PLC first goes to run you have zero pulses, you are then dividing by zero. See picture below, put the instruction at the end of ladder two, it will prevent the processor from faulting.

I don't think your method is going to be that accurate though, timers in a PLC are not that accurate.

overflowtrap.png
 
Last edited:
Make sure that you are only recognizing a pulse for the first cycle. If not coded properly, if your prox is made for more than one cycle you could be using the time between cycles as your duration. With a base of .01 I would guess(probably incorrectly) that you are either dividing by zero, or a very small time(It would have to be extremely small to cause your problem). Not sure about the zero, for that I would assume that you wouldn't be getting an overflow error. My money is on a needed one-shot and possibly a GRT...

Richard
 
It sound like when the PLC first goes to run you have zero pulses, you are then dividing by zero. See picture below, put the instruction at the end of ladder two, it will prevent the processor from faulting.

I don't think your method is going to be that accurate though, timers in a PLC are not that accurate.
Hi Micky,
You seem to be absolutely right. I will try this and will give you feedback.
Thanks a lot.
 
calculating pulses for 2 sec or 5 sec or 10 sec is not going to work if I want prepare a logic for 5 to 500 RPM range.
The method will work if you set your time value correctly. However, using timers will always have a built-in error.

If you do not understand the situation, the math, and the PLC, then almost any method you use will cause problems. On the other hand, once you do understand all the above, you can use many different methods.
1. I calculate the duration between 2 pulses. For exmple duration measured is 6 Sec. My timer base is 0.01 so my accumulated integer value comes as 600.
2. Now I divide 6000 (which is an integer constant) by this duration (which is 600 measured in step 1)
3. This should give me result as 10. This means 10 RPM.
This will only be correct if you have 1 proximity switch that is triggered once for each revolution. You could have two prox switches for all we know. Also, your DIVIDE operation should only be done 1 time at the end of the 6-second time period. If you do it more often, you will divide by 0 and cause a fault.

I would use Multiply instead of Divide, as shown below. This will get you an accuracy of +/- 5 RPM with an update time of 12 seconds, probably close enough for this type of project.

If you want closer readings, you could add a second prox switch and cut your time period by 1/2 to 6 seconds. Add 2 switches and you could cut it to 3 seconds.

RPM COUNTER.jpg
 
Last edited:
It's a wise practice with the SLC/Micrologix, to put a NEQ x, 0 when DIV by x is on a rung. In other words, guard against the divide by zero error everywhere there is a DIVide instruction with a variable denominator.

The overflow trap I frequently use will latch an internal bit before unlatching the system bit so that I have evidence that I can use while keeping the process running. If there are lots of files with the potential for causing the problem, I may duplicate that rung in each file, each with a unique internal bit address so I can track down the offending logic...similar to THIS post by the ever helpful Ron Beaufort.

Be careful when unlatching this bit and make sure it won't cause any risk to the machine, product, or people if you keep the processor running after any potential overflow fault is effectively defeated.
 
Last edited:
What is the rpm measurement being used for ? If you are displaying it to an HMI e.g. you also want a refresh rate. In that case I agree with counting pulses for 2 seconds, making the calculation, and sending it to the display. I'm just guessing that a refresh rate faster than 2 seconds would be too fast for an operator to read accurately. On the other hand, if this is part of a feedback loop, I would ask why you are not using a tachometer for an analogue signal ?
 
Support required for Allenbradley programming

Hello Everybody.
Pleased to join again.
Can some body let me know whether a Servo drive can be controlled through Ethernet or devicenet using Micrologix 1400 PLC? if yes then how?
I have run it successfully through PTO block but now interested to know whether it is possible through communication also or not.
If possible then how and which control is better?
Thanks to all in advance.
 
Sandeep its good to have you back but you should start a brand new thread for this different topic, it will greatly help you get the assistance you are looking for
 
Last edited:

Similar Topics

I'm looking for someone who is more experienced than to bail me out of this mental thought experiment. I am moving away from programmed alarming...
Replies
0
Views
969
Hello guys, I was reading programming manual of Allen Bradley and they mentioned few tips and I want to clear one tip tip: I/O module data...
Replies
3
Views
2,499
We have a trainer set up and I am trying to learn function block programming to reinforce my resume. In ladder I am pretty fast. I double click...
Replies
0
Views
2,070
My company is about to adventure in to servo motion. I have never programmed them and I am just looking in to it. I am just looking for any tips...
Replies
16
Views
12,629
We have used many AB VFDs, once installed, and under 480vc power, are commissioned via appropriate Drive Software, and network connectivity...
Replies
8
Views
4,871
Back
Top Bottom