Sign in to follow this  
Followers 0
martynhudson

Maths over flow with Div command

4 posts in this topic

I am a very simplistic programmer of ML 1500 who just has to manage one packaging machine design. I have been asked to add code to the program to enable a HMI to read the machine speed. I have used the clock pulse from the encoder on the machine whicj is an input to the plc and run a RTO via some simple latches to give me a cycle time. When I use the Div command to turn this into cycles per minute Ie Div source A (6000) mil sec By Source B T20 Acc it displays the machine speed. Great. Next I need to reset the T20 before I re examine the machine speed. At this point the unit faults out with maths overflow when the value of T4:20.Acc is zero as the div command does not like 6000 divided by zero and reads 32767. I have worked around by removing the Res command and using the HMI to write the value 1 to T4:20.ACC to refresh the speed but this is not really satisfactory along with the fact I am baffled why anything divided by zero = 32767. Can anyone help this idiot please. Martyn

Share this post


Link to post
Share on other sites
Well, the real issue is that dividing by zero, mathematically speaking, is infinity-- or impossible, depending on who your teacher was. The processor went as large as it could (32767) before giving the overflow error. A way to keep it from doing the divide by zero in your instance would be to check that the T4:20.ACC is not equal to zero (using the NEQ instruction) just before the divide instruction. That way in that one instance where the timer is reset, you won't go into a tailspin. Hope this helps!

Share this post


Link to post
Share on other sites
Iv always used clipping in my programs to say if this number goes under 5 write a 5 to it. It come in handing setting up analog cards

Share this post


Link to post
Share on other sites
limit checking is one way to overcome this problem, but sooner or later one of your instructions will set the overflow status bit..... that automatically also sets the "Overflow Trap" bit S:5/0..... and if that bit is set at the end of the program scan - the processor will fault out. almost without exception, every Logix500 program I have ever come across has an unconditional rung as the last rung of file 2.... OTU S:5/0

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