Sign in to follow this  
Followers 0
kcor

HSC as rate to show rpm

6 posts in this topic

Have another question that deals with calculating the rpm. Can the HSC counter be set up to show rate. I am using a micrologix 1200 and a AB encoder that gives 360ppr. I am using the HSC input as a 0-360 degree cam to determine when to turn things on. What I was looking at was using the HSC input and that same encoder on a setup on the bench and use the encoder to tell me the rpm that a shaft that I have mounted on a small motor on the bench to tell me the rpm. If I leave the reset input disconnected from the encoder, the counts will continue to increase as I turn the motor shaft. What would be the best way to use that to determine the rpm. Any advice.

Share this post


Link to post
Share on other sites
How many counts per revolution? 360? I think it will overflow at 92 revolutions. How many rpm is it expected to run at?

Share this post


Link to post
Share on other sites
I like to update things like a rpm display (on an hmi) about every three seconds. You may need a different number. I would accumulate counts for three seconds, divide by 360, and multiply by 20. That would give you rpm with a three second update.

Share this post


Link to post
Share on other sites
if you put your input into a counter for every revolution you get a count value of 360 so if you have timer set for 1 minute and then look at the acc value of the counter you will get a value that when divided by 360 = rpm slight problem of course is that as the actual rpm rises so the acc value will approach it's limit where overflow occurs (and the counter reset) you may have to use a timer set in seconds or hundreths, or if going slower than might have to use hours or days obviously when not using minutes as the time you have to correct for this to give rpm. If things are happening at high speed you might have to look at a certain number of counts triggering an event, everything of course depends on what is driving the roller and it's diameter Edited by comeng

Share this post


Link to post
Share on other sites
Thanks Will get more time tomorrow to experiment. This something I tried real quick this afternoon on the bench before I left and it worked. Any advice. Is this a good way to do it? Did this after doing a search on the ab site for HSC for rate. hope you can read the attachment BencTest.doc

Share this post


Link to post
Share on other sites
The HSC accumulator is a 32 bit value. That means that with a 360ppr enconder you won't overflow until after 5,965,232.35 revolutions. And when you do overflow its straighforward math to account for it. One problem with resetting the accumulator as you did is that you delete any counts which may have occured while you were processing the ladder. If you don't reset and just let it roll over then you will get a more accurate count. You will need three L registers. A current_value, a last_value, and an elapsed_counts register. You also need to set the bit S:2/14. On a periodic time basis examine the HSC accumulator and determine how many counts have elapsed since the last time. Immeidately store the HSC accumulator value in a L register for current_value so that you don't have to worry about it changing while you do the calculations. Now subtract the last_value from the current_value and place it in elapsed_counts. Now move the stored current_value to the last_value register for the next time. This way any HSC counts that occur during this time will be accounted for in the next time interval. When you have a rollover from positive to negative (crossing 2147483647 to -2147483648) thats where the beauty of two's compliment binary math comes in. On the sample where roll over occured elapsed_counts will be negative, but its magnitude will be correct. So simply multiply the result in elapsed_counts by -1 or use the ABS instruction. Do this only on the scan where roll over was detected. Aside from that one time, it doesn't matter if the HSC accumulator is positive or negative, the elapsed counts will be spot on. Right afterwards, make sure you reset the overflow minor fault bit S:5/0, and depending on how you want your other math to function, you may want to clear S:2/14. Now diivide elapsed_counts by 360. Multiply by the elapsed time between samples in seconds and you have revolutons per second, which you can convert to RPM by multiplying by 60. MOV HSC:0.ACC CURRENT_COUNT //CURRENT_COUNT IS A LONG OTE S:2/14 SUB CURRENT_COUNT LAST_COUNT ELAPSED_COUNT //LAST_COUNT AND ELAPSED_COUNT ARE ALSO LONGS MOV CURRENT_COUNT LAST_COUNT ABS ELAPSED_COUNT ELAPSED_COUNT DIV ELAPSED_COUNT 360 REVOLUTIONS //NUMBER OF REVOLUTIONS DIV REVOLUTIONS SAMPLE_INTERVAL REV_PER_SEC //SAMPLE_INTERVAL IS THE TIME BETWEEN RPM SAMPLES MUL REV_PER_SEC 60 REV_PER_MINUTE OTU S:2/14 OTU S:5/0 On the first scan reset the HSC ACC and CLR LAST_COUNT. Edited by Alaric

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0