floating point number errors

[Guest beavis]

I placed some wonderfull code into my slc500 that uses a floating point number to change a process parameter. The number is initialized at the start of production and then after every machine cycle this number is multiplied by 0.5 to cut it in half. for instance start=0.2 next =0.1 next=0.5 etc..... One day this code was changed to have no effect on the process but this number never being initialized continued to divide itself by 2 after every cycle of the machine until one day PROCESSOR FAULTED came up. We reloaded the program and it will run for a while, but then fault again. The fault occured when the value in the floating point register gets to small. At fault it was something like 545664e-39 This number was not used in any division or formula its only use was in a subtract statement. Why should the processor fault instead of just converting the number to zero after the smallest storable value had been reached???

[Sleepy Wombat 27]

Not having played with AB for a while it sounds like an overflow perhaps.... You can check this and i think clear by    S:5                  B3:8 - Overflow has Occured ---[  ]---------+---(L)      0          |        12                 |                 |     S:5                 +---(U)                            0 Perhaps someone else might be able to shead some light....

[Guest Guest]

The third number in the sequence I gave as an example should be 0.05 not 0.5. The floating point value in this code got progressively smaller every iteration until it was near zero. And it was not used in a division so I think overflow was not the problem. Thanks for your help

[Snerkel 0]

You have an infinate loop, the number can never get to true zero as you know. The designers of the processor had a number of choices on handling overflows, the way AB decided (and I agree with it) is that a fault flag is raised, this then allows the user to decide how to deal with it. S:5/0 maths overflow bit will be set, if you reset this bit in the last rung of ladder 2 then the processor will never fault, however you could also set your floating point value to zero on the same rung. Something like -----| |-----------------------------(OTU)     S:5/0           |                    S:5/0                     |                     |                      -----------------CLR                                              F8:0 Pasteable version XIC S:5/0 BST OTU S:5/0 NXB CLR F8:0 BND To view this open RSlogix and paste the line into a new rung by double clicking the red box to left of rung and pasting into the box that opens. Edited 24 Oct 2004 by Snerkel

[Ken Moore 23]

I use the example sleepywombat posted in all my AB applications. With AB you can get overflow flags for lots of reasons, not just division. Any time a request to write a value larger than the register can hold, you will get an overflow flag. I think this is happening in your case. I do not remeber the exact values a FP can be in AB, but if you try to exceed them the overflay will be set. Just add the logic as the last line in Ladder 2, and see what happens. Ken

[Guest Guest]

I appreciate all the responses but I would like to say again that my floating point number was approaching zero as in something*e-39. This is not an overflow and not an underflow. I think it is yet another bug in the slc500 system. If there is another explanation I would love to learn how to avoid this. thanks beavis

[Sleepy Wombat 27]

Read the above posts again....... It is an overflow because it is such a small number... 10 pwr -39 is basically 0.000000000000000000000000000000000000000022133 Simply post the example code in your program....

[Ken Moore 23]

From RSLogix500 help file: F8 FloatingPoint This file stores a # with a range of 1.1754944e-38 to 3.40282347e+38. SLC 5/03 OS301, OS302, SLC 5/04 OS400, OS401 and RSLogix 500 - Copyright Rockwell Software 2000, 2001, 2002 So if you have a value that is e-39, you are trying to exceed the capacity of the memory registers, and the overflow flag is being set. Just follow everyones advice and use the posted code as suggested. If you're not willing to listen to the advice given, why did you ask for it? Ken

[Guest]

Greetings beavis, obviously YOU (as a human) are thinking of a very small number ... the PLC (as a machine), on the other hand, must use a series of bits (ON or OFF signals) to represent that same very small number ... the problem is that the PLC has been designed to use only a definite limited number of bits to represent the very small number ... once all of those assigned bits have been used, the PLC is unable to represent a number any smaller ... that's where the "overflow" or "underflow" condition results ... the people who designed the PLC decided (rightly or wrongly) that 32 bits (two words worth) would be enough to represent very small numbers and very big numbers ... you've been given the range in a post above ... that's just the way this "floating point" numbering format works ... you can find some more detail on this topic here: SLC-500 Instruction Set Reference Manual on page F-6 [Adobe Reader page 608 of 648] ... notice how the "good stuff" is always near the back of the book? ... I hope this helps ... best regards, Ron Edited 27 Oct 2004 by Ron Beaufort

[Guest Guest]

I accept your responses as the right answear. I do not agree with AB if they chose to handle a diminishing floating point number with an error instead of truncating it to zero. My pc will gladly run a program without error that reduces a floating point value indefinately eventually calling it zero without requiring a re-boot. Thanks all Beavis

[Snerkel 0]

The difference between a PC and PLC is that a PLC is designed to control systems that may cause serious damage or injury, a PC is not. As I said before the number can never be really zero, if AB or another PLC manufacturer decided to just zero the value this could have all sorts of knock on effects. If the engineer fails to correctly handle an overflow then the PLC should stop, if the engineer is aware that the value may overflow then the engineer needs to program suitable handling routines, else the PLC will go for the safest option which is to stop the process. While not always the best course of action AB have given the engineer the choice on how to handle it, the value may be a genuine unforseen error, in which case who knows what unpredictable action the machine may do if that overflowed value suddenly becomes zero. If as an engineer you decide that a value less than x should be zero then you only need to do a compare and zero the value if necessary. Overall the system gives the engineer the choice on what to do, afterall the engineer knows his process and should be able to handle the situation as the engineer sees fit, this system gives the engineers the control they should have.