what is the largest value that a float number can reach before causing a fault?

edit:
for a slc5/05

open RSL500 help file and lookup Data Table Files:

if you're just "typing it in" try 3.402823466E+38 ... the book rounds it off to the number that panic mode listed - so the number from the book won't really quite "fit" if you try to type it in as a test ...

survival tip: if you try to manually type in a number that's too big, you'll see this pop up message (with the correct range of numbers) ... and that won't usually cause a fault - as long as you're just TYPING it in on the data table window ...

[attachmentid=6470]

anticipating your next question: are you trying to add the value 1 to the floating point location over and over to increment the value? ... if so, there's a limit beyond which the value will not go any higher ... basic idea: the floating point math gets "rounded off" and can't add just 1 to the total anymore ... if that's what you're trying to do, then you'll never get the fault condition that you're expecting - because the number quits increasing before the "overflow" point is reached ...

it would probably be a good idea to tell us what you're trying to do ... simple questions like this seldom have simple answers ...

I needed a flow totalizer

I have a 4-20 input from a flow meter that I scaled to gallons per second(gps) and I used S:35 (converted to seconds) multiplied by my gps to figure out how many gallons per scan and add it to a total that will be wiped at midnight. I just want to make sure I wasnt going to go over the limit but i shouldnt get anywhere close to that in 24 hours. I just couldnt find that number anywhere.

by the way this is my first attempt at a flow totalizer and if anyone has a better way please tell me.

thanks for the replies

it would probably be a good idea to post your program ... that part about using S:35 doesn't sound quite right ...

it would also be a good idea to tell us what range of values you expect ... how many gallons per second? ... how many gallons per day? ... what is the range of your transmitter? ... how accurate does this thing need to be? ...

[attachmentid=6472] here is the the flow totalizer from my program. as far as i can tell it should work. I used S:35 thinking that it would give me the most accurate results.

unfortunately I dont have the answers to your questions Ron.

just found out the flow meter has a range of 0 - 5000 gpm so even at 5000gpm * 60min/hr *24 hr/day = 7200000gpd max

you really need to nail down your hardware first ... unfortunately there’s nothing shown in your program’s I/O Configuration list ... from the program you posted, it looks like you’re planning to bring the signal from your input sensor into F8:3 ... you can MOV it there, of course, but normally with an SLC-500 system, the input comes in from the field device as an integer value (not as a floating point value) ... that “integer-without-a-fraction” type number is probably going to be the limiting factor in how much resolution you can expect from this system ...

that’s not to say that the totalizer idea won’t work - it will ... it’s just that you have to be realistic about how much resolution/precision/accuracy you need to provide in the final total ...

major idea: there are basically two things to consider in your approach ... (1) how “fine” will the data from the input signal be sliced? ... (2) how “fine” will the sample time be sliced? ...

from what you’ve posted so far, it looks like you’re working only on the “sample time” issue ... with a 0 to 5000 gpm range on your field instrumentation, the number which has the greatest limiting effect on your results might well become the data from the analog input module - and not the “time between samples” ...

basic plan of attack:

find out what type of input module you’re going to be using ... find out how many “steps” are available in the integer data as the flow ranges between 0 gpm and 5000 gpm ... divide to find out how many gpm are represented by each “step” in the data ... once you’ve done that, try working through the math again ... if I understand what you’re trying to do, then I think that the accuracy you’re trying to develop with S:35 isn’t going to work out the way that you think it will ...

going deeper:

once you’ve nailed down the input module, pick a number somewhere about midrange as a sample reading ... say “8000” just to have a number for the data reading ... manually calculate how many gpm that represents ... now manually work the math in your totalizer - assuming that the actual flow - and the sample number “8000” - both stay perfectly stable all day ...

now ...

pick another number as a sample reading ... say “8001” just to have a number for the data reading ... manually calculate how many gpm that represents ... now manually work the math in your totalizer - assuming that the sample number “8001” stays perfectly stable all day ...

now ...

pick another number as a sample reading ... say “7999” just to have a number for the data reading ... manually calculate how many gpm that represents ... now manually work the math in your totalizer - assuming that the sample number “7999” stays perfectly stable all day ...

see where I’m going with this? ...

this simple “Fred Flintstone” approach should help you see whether or not the resolution/precision/accuracy that you require is going to be available in the long run ...

important: while working through the steps above, be sure to notice that the INTEGER data readings coming in from the analog input module will always move in “whole number” increments ... in other words, just moving those raw values into a floating point location (like F8:3) won’t add any accuracy/precision/resolution to the data at all ...

disclaimer: all of this is based on what I THINK that you’re doing ... I might have misinterpreted something ... feel free to elaborate if you think that might be helpful ...

hope this helps ... good luck with your project ...