[Logix5000] Dividing by zero

Hi guys,

One thing I'm running into is dividing by zero, and I'm wondering how best to deal with it.

For the coagulant chemical pump dosing, I divide a bunch of variables by total plant flow to work out pump speed. The problem is, when the plant isn't actively treating water the influent flow is exactly 0. Thus, the problem. It creates thousands of minor errors, and while it's not creating a "problem", per say, I'd really like to clean that up and keep things nice and tidy.

I was wondering if there is a better way to take care of this and how you guys have dealt with such issues. One thing I could do is put a compare block in front of the computation block, that says to only energize that rung if the influent plant flow is above 0. But I wonder if that's best practices, or more hacky. Is there a better way to deal with this?

Thanks!

Check whatever variables are being used in your denominator before the DIV or CPT takes place. If any will cause the divide-by-zero, set your result to zero and branch around the DIV/CPT.

The compare [GRT] is the way I do it when I need to.
HTH

That's the best way I know of to deal with it. You will need to decide if you need to do something special with the output if the equation is not active.

Keith

what you suggest looks like the best solution to me.
The compare block in beginning of the rung and only do the device if is greater than 0
clean and simple

defcon.klaxon said:

I was wondering if there is a better way to take care of this and how you guys have dealt with such issues. One thing I could do is put a compare block in front of the computation block, that says to only energize that rung if the influent plant flow is above 0. But I wonder if that's best practices, or more hacky. Is there a better way to deal with this?

Click to expand...

This has been a problem since the beginning of programming, whether in a PLC or a standard PC. Some programming languages detect divide by zero errors for you, or the divide instruction provides some kind of useful error message/bit. The "Correct" solution is for the divide instruction to do the compare you mentioned internally, but you can do it yourself if it doesn't. Theoretically, we should be doing it for every divide instruction, but you can probably get away with it for just the ones you think could divide by zero. Even more theoretically, we should be checking every single input to every single function/instruction/subroutine/AOI to make sure it is valid.

When you hear about programming errors that can cause security vulnerabilities in PC programs, not checking for divide by zero is one of the most basic ones.

One "trick" that sometimes works is to instead of dividing by a number, multiply by its inverse. But it is always good practice to filter the parameter for acceptable values.

OK, let's multiply by the inverse of zero. What was that value again?

JeremyM said:

Check whatever variables are being used in your denominator before the DIV or CPT takes place. If any will cause the divide-by-zero, set your result to zero and branch around the DIV/CPT.

Click to expand...

This is my preferred method.

One thing to be careful with the method of only doing a greater than comparison to perform the divide is that that could leave you with incorrect values in your resultant tag. For example, if on the previous scan the result was 7, you may want to set that to a known value as opposed to leaving whatever was in there before there.

bernie_carlton said:

OK, let's multiply by the inverse of zero. What was that value again?

Click to expand...

At the result is a valid number, and will not fault the controller. Whether its an acceptable value for your process, is another issue.

-Benaiah

jkerekes said:

One "trick" that sometimes works is to instead of dividing by a number, multiply by its inverse. But it is always good practice to filter the parameter for acceptable values.

Click to expand...

That's the best way to do it. I also stick a NEQ in front just to be sure.

Originally posted by jkereses:

One "trick" that sometimes works is to instead of dividing by a number, multiply by its inverse. But it is always good practice to filter the parameter for acceptable values.

Click to expand...

So, how did you get the inverse in the first place?

Keith

Say you want to convert feet per minute to feet per second.

FPM/60=FPM

OR

FPM * .01666= FPM

1/60 seconds = .016667

I use this most of the time when I am dividing for stuff like gallon or flow conversions as well as VFD hertz to FPM conversion. Generally more for constants then anything else.

bernie_carlton said:

OK, let's multiply by the inverse of zero. What was that value again?

Click to expand...

I'm also waiting for a good explanation about this point. If x/0 is a problem, is x * (1/0) a good solution?

I guess it depends on what you call a good solution. If you are converting from a flow range of million gallons per day (mgd) to gallons per minute (gpm) you can go about it several ways.

flow (gpm) = flow (mgd) / 1440 (minutes in a day), zero flow from the flow meter will cause the math error

another option;

flow (gpm) = flow (mgd) * .00069444 (the inverse of 1440), zero flow will not cause the math error.

The term "good solution" is subjective. Would someone looking at the program rather see 1440 or .00069444. I have seen programs where I spend too much time trying to figure out what the formula means (usually feel real stupid once I figure it out). I would have an easier time figuring out what 1440 was as compared to .00069444.

You also should understand what the OP means by variables. Are these "variables" data from devices or are they from operators, for example- concentration %, specific gravity, or % solids.

Variables entered from places like HMI's should be validated before being accepted.

As far as the NEQ in front of calculations, this can be deceiving because if you don't do the calculation because of a zero value, the result of the calculation is the same as it was the last time it was not zero. That is unless you zero out the storage register on a zero value.