Unexplained -NaN in Micrologix controller

There are two invalid numbers in the IEEE-754 float format. The first is +/- infinity. The other is +/-NaN. Infinity is indicated when bits 23-30 are all set and no other bit in set. If any other bit is set then NaN is indicated.

The RSLoigx500 ladder logic editor displays NaN under the address in the instruction for both values. However, if you open the data file then you can see 1.#QNAN for an invalid number, and 1.#INF for infinity.

Can you tell us if the invalid value is actually 1.#INF or if it is 1.#QNAN by checking the value shown in the data file. If it is 1.#INF then you may have a divide by zero occurring sometimes during scaling.



You can detect if bits 23-30 of the float are set in your ladder, but due to a RSLogix-500 compiler limitation you can't directly access the bits of a float like you can in Logix5000. To access those bits you need to first copy the float to two consecutive integers. Then do a MEQ on the second integer.

CPW F8:2 N7:100 2
MEQ N7:101 32640 32640 OTE INVALID_NUMBER_FLAG.
You could use that to trap and save the value of I:1.2, and F8:44 and F8:45.

So as other things at work took precedent, I sort of let this anomalous fault go, until yesterday when it reared it's ugly head once again.

First off, to answer TConnolly, the value displayed on the F8 address isn't NaN, INF, or QNaN. It displays as "-1.#IND". In order to implement what you described to analyze the bits of the Float, I'm guessing I would either need to run the program in the emulator or on a controller (after clearing the fault, but leaving the bad float value in) while setting the math overflow bit open prior to the end of the scan, so that the instructions to break down the float can actually occur.

But here's the new occurrence:

I did set up the trap maxketcham described, but it did not help catch this re-occurrence since A) it happened on a different piece of equipment that didn't have the trap in the logic, and B) it happened to a float being scaled from an analog output value.

More or less the same situation as my original post, except this time an analog output raw value is being scaled in an SCP using constants for both input and scaled minimums and maximums (6241-31208 and 0-100 respectively) for an engineering unit value to be displayed in the HMI. That engineering unit value, another F8 address, displays as "-1.#IND". The raw analog output value used for the SCP input at the time of the fault is 6241 (4mA as setup in the analog output module).

NOTE: In this instance the scaling minimums and maximums are constant which seems to rule out HMI comm interference writing erroneous values into the SCP instruction. The only variable here is the raw value off the input module. That being said, the HMI is still reading the F8 output of the SCP and this tag in the HMI is still set to read/write.

I'm tempted to say this is a faulty I/O module (and that my previous problem was a faulty I/O module), but that would be quite a speculation. I will try and analyze the bits of the float in this occurrence and the previous one as TConnolly described and post back if I can get anything.

Ok, it was a bit tricky using the emulator, but here's what I got as far as a bitwise analysis of the -#1.IND float value.
BIT 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

WORD 1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
WORD 2: 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0

I'm assuming that gives a floating point (in bits) as:

00000000000000000000001111111111

So depending on whether you start at 0 or 1, bits 22-31 or 23-32 are set to 1 which seems to somewhat coincide with what TConnolly was saying, however, if I just plug these into a 32bit binary to decimal float converter, I get:

1.43352832900428786355497536371E-42

Which seems like a perfectly valid value. So what gives?

Looking deeper on Knowledgebase I found this:

The REAL data type now shows a 32-bit (4-byte) IEEE floating-point value with the following range:

• -3.40282347E38 to -1.17549435E-38 (negative values)
• 0
• 1.17549435E-38 to 3.40282347E38 (positive values)

The REAL data type also stores ±infinity, ±NAN, and -IND, but the software display differs based on the display format.


DisplayFormat: Equivalent:

Real +infinite 1.$
- infinite -1.$
+NAN 1.#QNAN
-NAN -1.#QNAN
-indefinite -1.#IND

Exponential +infinite 1.#INF000e+000
- infinite -1.#INF000e+000
+NAN 1.#QNAN00e+000
-NAN -1.#QNAN00e+000
-indefinite -1.#IND0000e+000


The software also stores and displays the IEEE subnormal range:

-1.17549421E-38 to -1.40129846E-45 (negative values)
1.40129846E-45 to 1.17549421E-38 (positive values)



From another knowledgebase article:

Valid range is + - 1.175494e-38 to + - 3.402823e+38
PLC5-Family processors store information in IEEE Standard floating-point format.

So this certainly brings up some interesting questions, but most importantly, how on earth does a raw analog value with 16 bits of precision (-32678 to 32676) being scaled with constants yield such a crazy float value. That number isn't even in the numerical possibilities of the SCP instruction (all 65535 of them) UNLESS something is intermittently corrupting the other constants in the calculation. I did forget to mention that the constants (minimums and maximums) are in the SCP with decimal points so they are treated as floats, but I think since the destination is a float address, they are all treated as floats anyway. Anyone have any thoughts on this?


EDIT: The format got butchered on the knowledgebase quotes, but here are the links for those who can access it:
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/55156
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/7765

maxketcham said:

-indefinite -1.#IND0000e+000 is your problem

Click to expand...

Can you elaborate on this?

Just a thought... I had a plc5 once that we were using as a measurement system. We did some division to get time stamps. Apparently the plc had trouble with certain numbers and instead of a simple division like "2.0" we would get "1.9999999998". That screwed up our measurement tracking so we had to adjust our time base. Something similar may be happening in your plc. Finding the number causing it may be trouble. You might try some conditioning before the number is entered in the SCP.

can't elaborate on it. just had this problem before with the SCP using an analog input that was occasionally going over / under range and that is what I was seeing. reason I said to do a min/max check to find it. becomes a -j problem then I think?

remember algebra and the j operator

think of it this way either you are dividing 0 by a number or a number by zero