1.#QNAN on PLC 5/04

[Electrically_Bound]

I noticed in a PLC 5/04 program I have a 1.#QNAN as a value for a floating point number. After some Googling I have come to know that QNAN stand for Quiet Not A Number - a term used in lexicon of floating point numbers. It looks like that the source of this number has been a caused by dividing 0 by 0. This plc calculates the instantaneous diameter of a roll by dividing the line speed by the winder speed (I'm simplifying this equation a bit). Now if the line stops running, I can see where you would get an impossible result since both speeds are zero.

My real concern is how does the PLC handle this condition? This value is used in different parts of the program by different types of instructions. Will the PLC just keep chugging along until the calculation no longer produces the impossible number or does it cause a fault. I'm thinking about filtering the sppeds before any math is done by effectively saying that IF SPEED = 0 THEN SPEED = .1

Any thoughts on this?

I did find a thread on this forum that discussed QNAN to some extent, but I didn't find any info on how Allen Bradley's plc's respond to this condition.

 

[gmferg]

If you see the QNAN value for a floating point and the PLC is not faulting then an OTU S5:0 must already exist somewhere in your program. This prevents the PLC from faulting due to a math overflow error.

 

[OkiePC]

SLC 5/04?

If so, a divide by zero will cause S:0/1 "Math Overflow" to be set. it will also set S:5/0 "Overflow Trap". If S:5/0 is still set at the end of scan, the processor will halt execution and go into a Major Fault.

So, if you are using a 5/04, and it stays in run mode with a divide by zero, there is probably logic that is clearing the S:5/0 bit just before the end of the logic scan.

Paul

 

[Mark Buskell]

We also had problems years on a PLC5 where we where taking our flow setpoint and dividing it by our actual flow from a meter.
Then we would multiply it by a 100 to convert it to a percentage.
What was happening is that sometimes when the flow rate nearly matched the setpoint we would get the dreaded "NAN".

We then put the minor fault unlatch at the end of the program to overcome the PLC fault. Later on, I redid the math to prevent this scenario from happening.

 

[robertmee]

I ALWAYS without exception precede any divide or CPT statement with a DIV in it with NEQ Denominator 0. Get into that practice and do not rely on unlatching the overflow bit, IMHO. If you must have some evaluation of the equation when zero is present, use a parallel branch to stick a number in the result that means something. Either zero or the largest value practical.

 

[Electrically_Bound]

The dreaded QNAN error has been fixed by making sure that a a zero never makes it's way into the the divisor of a divide instruction. In this instance I simply put in some logic that effectively said that IF X = O THEN X = .01 This may not be the most elegant of fixes, but in this instance it is quite adequate and eradicates the QNAN problem.

Thanks for the the info on math overflow bits and things of such sort; that is something that I am weak on and will study further.

I will now make sure to use multiplication whenever possible and, if I must use a divide, make sure that I test for a zero condition and take the appropriate measures to handle it.

The remaining question is how were the plc instructions handling the QNAN. What happened when it used in a GRT or MOV statement?

 

[sandwich]

I had this after a plant wide power failure. QNAN was in the registers for some 4-20mA devices. A cold boot of the SLC cleared the problem.