1.#QNAN error

[Zoyalan]

Hello, I am average in automation, we had power outage in our factory, and one of the conditions on the SCADA was 0 regardless of any change so I opened the code related to the issue on studio 5000 and found this error, is there a way to prevent this error ? And if not is there a way to detect if there are errors in my code like this, I attached a picture regarding that.

 

[IO_Rack]

The tag with the NaN is getting a bad value from somewhere. You'll need to do a cross reference on that tag and see where it is 'Destructive', or where it is being written.

The NaN error you are seeing is "Not a Number". The REAL data type of that tag is a (somewhat) complex format to allow computers to interpret floating point numbers. It is defined in the IEEE 754 standard. Whatever data is currently in the tag is not compliant and is unable to be interpreted by the PLC program.

 

[Peter Nachtwey]

I would do two things.
1 make sure that non-floating point data from someplace is not being written to your floating point variable. Non-floating point data probably isn't in a floating point format.
2. Check the values being used to calculate the offending value. Usually, floating point calc don't generate a NaN so the chances of this being the problem is low.

I would check for #1 first.

 

[parky]

NAN usually means not a number ib other words either there is some corruption in the data or the format is wrong.
Have had this a few times in modbus it could be that the bytes or words are swapped or both ( depending on the MB protocol or there is an offset of the registers when reading a float some MB's have an offset of either 0 or 1.

 

[Zoyalan]

I would do two things.
1 make sure that non-floating point data from someplace is not being written to your floating point variable. Non-floating point data probably isn't in a floating point format.
2. Check the values being used to calculate the offending value. Usually, floating point calc don't generate a NaN so the chances of this being the problem is low.

I would check for #1 first.

It is a very large program since it controls the whole line, is this even doable ? And it is normal that I face this error in case of line shutdown ?

 

[chavak]

It is doable. Follow what others mentioned.
1. Click on the tag OT3801_Right.EWMA and press Ctrl+E. [ This displays the address usage ]
2. In the window that appears, look at the 'Destructive' column as IO Rack suggested. Double click on the items it says 'Y'
3. The tag values are altered/updated there. Most probably an illegal mathematical operation is happening causing this, like divide by 'zero'
4. Edit the rung, and prevent it from executing the rung - say for eg. the dividend is greater than zero

Regards

 

[IO_Rack]

OT3801_Right.EWMA is receiving a bad (Non Floating Point or Non REAL) value. You must find the origin of this data to find the problem. Right click on the OT3801_Right.EWMA tag and choose "Cross Reference". In the Cross Reference window, find the item with a "Y" in the Destructive column. This is where it will be receiving the bad data. << This is what Peter and I are asking you to do. These tools are available to help you with very large programs.

No, it's not normal but it's not a problem with the PLC. It's a problem with the system that no one here knows anything about. Is this a position? Is it a motion controller? Can you post the program?

 

[robertmee]

As has been stated, find the destructive instances of that tag. More than likely its a result of improper code attempting to divide by zero. An easy fix, as precede any DIV or CPT statements with division by a compare of numerator <> 0.

 

[Peter Nachtwey]

Doesn't a divide by zero cause a divide by zero fault instead of a NaN?
You would think that PLCs would have an error log that would show what caused the fault.
We have this for our motion controller.

 

[robertmee]

Doesn't a divide by zero cause a divide by zero fault instead of a NaN?
You would think that PLCs would have an error log that would show what caused the fault.
We have this for our motion controller.

Both...processor logs it as a minor fault, but evaluates to NaN.

Tech note Sign In

 

[Zoyalan]

NAN usually means not a number ib other words either there is some corruption in the data or the format is wrong.
Have had this a few times in modbus it could be that the bytes or words are swapped or both ( depending on the MB protocol or there is an offset of the registers when reading a float some MB's have an offset of either 0 or 1.

What MB means

 

[drbitboy]

What MB means

ModBus is what I think was meant.

 

[kekrahulik]

I'm not sure if you get the QNAN when you divide by zero, but as mentioned, I always condition a DIV statement that the divisor is NEQ 0.

I do know that I have achieved QNAN when my math blew up and the number got too big. Divide by zero is the ultimate big number, but the PLC taps out before it reaches infinity.

 

[robertmee]

I'm not sure if you get the QNAN when you divide by zero, but as mentioned, I always condition a DIV statement that the divisor is NEQ 0.

I do know that I have achieved QNAN when my math blew up and the number got too big. Divide by zero is the ultimate big number, but the PLC taps out before it reaches infinity.

The newer studio gives you 1.$ instead of QNAN, but I have seen in the past QNAN was the result. KB is ambiguous saying for a divide by zero you could have:

"REAL tag value will be shown as something with letters in it like -1.# QNAN or 1.$ or 1.IND or possibly some other non-numeric value."