Detecting QNAN in Control logix

Hi All,

I have relatively obscure problem with floating point numbers.

My setup is a CompactLogix with a Prosoft MVI Modbus TCP Card. The Prosoft card is retreiving a floating point number from a remote device via Modbus TCP and transferring it to the Compactlogix CPU via the backplane. i then use a CPS instruction to convert the two INT's into a REAL datatype.

Somewhere along the line the data is being corrupted (or timing is screwing up) and the result is that i get a 1.#QNAN (ie not a number) error occasionally.

What i need is a way to detect that the data has errored so i don't use it until it becomes good again. Does anyone have any ideas? Ive tried GRT > 0, but that allows a QNAN through.

Hmm, without much knowledge of what's going on this is what I'd do:

Do calculations, store to a temp REAL number called temp

if !Error bit
result = temp

Honga said:

if !Error bit
result = temp

Click to expand...

The problem is determining the !Error bit

The "S:Minor" minor fault and "S:V" overflow bit both are true when you divide by zero and create an undefined number (1.$ or 1.QNAN in RSLogix 5000).

Edit: Found an RA Knowledgebase article addressing exactly this issue:

http://rockwellautomation.custhelp.com/app/answers/detail/a_id/59895

Process the number by multiplying it by 1.0 to intentionally create a S:V overflow, and you can then avoid processing it in your actual code.

Those not-a-number are always the result of an operation with an invalid result; the COP or CPS instruction shouldn't cause one by itself.

Does the 1.QNAN show up in the result of the CPS instruction, or in the Input table of the MVI69, or somewhere else down the line ?

Ken Roach said:

The "S:Minor" minor fault and "S:V" overflow bit both are true when you divide by zero and create an undefined number (1.$ or 1.QNAN in RSLogix 5000).

Edit: Found an RA Knowledgebase article addressing exactly this issue:

http://rockwellautomation.custhelp.com/app/answers/detail/a_id/59895

Process the number by multiplying it by 1.0 to intentionally create a S:V overflow, and you can then avoid processing it in your actual code.

Those not-a-number are always the result of an operation with an invalid result; the COP or CPS instruction shouldn't cause one by itself.

Does the 1.QNAN show up in the result of the CPS instruction, or in the Input table of the MVI69, or somewhere else down the line ?

Click to expand...

Thanks for your suggestion Ken.

the 1.QNAN looks to appear when the source device updates its data and the MVI module has a brief period where the two 16 bit INTs representing the REAL are mismatched. The MVI seems to blindly send this data to the CPU even though it is setup to realise that the memory location refers to a floating point number. Anyway the result is that for a significant number of scans the CPU computes a NAN result when the two mismatched INTs are copied to a REAL tag.

Anyway, it ended up that the simplest solution can often be the easiest to overlook. I prefaced the computation using the NAN prone data with a LIM instruction which weeded out the NAN value.

Something to be beware of when transferring floating point data with a prosoft MVIxx module.