MicroLogix Data Logging

Does anyone now why a Float file can't be used in the Data Logging configuration? Or am I missing something?

When I try to setup to read a float file I get a compiler error number:4107. Not that I can't get what I want thru a interger file, I'm was being lazy and using a program that I already wrote that stores that data needed in a float file.

Just curious why it won't allow data from a Float.

From the help file:

"Address to Log

Type the addresses here that you want sampled in the current queue (set of data). The address can be a bit address, or any 16- or 32-bit word. After typing an address, click Accept or Press [Enter] to place the address in the address list.

RSLogix 500 - Copyright Rockwell Software 2000, 2001, 2002"

Check that out... a copy and paste from the help file adds a copyright notice!

So anyway the answer is 'cuz the help file says it can only handle 32 bits.

note to self start reading the help files.

Im sure there's a fancy technical reason... maybe someone with "the knack" can elaborate.

I'm confused.

Your right, it definately doesn't work, but the floating in a Micrologix is a 32 bit number. 2 Words, the same as a Long Integer which does work in data logging.

Just trying to make sure we haven't missed something though the data logging configuration is pretty straight forward

wait... thought a floating was like 38-39 digits long? that wont fit in 32 bits.

No, it's 32 bit.

The Floating Point File is a general purpose file consisting of 32-bit IEEE-754 floating point data elements.

Click to expand...

It's definately 32 bit and it definately doesn't work at the same time. Bets be

jedft said:

wait... thought a floating was like 38-39 digits long? that wont fit in 32 bits.

Click to expand...

No, it can represent up to 8 decimal digits and an exponent that can range from +38 to -38. That is 23 binary digits, an 8 bit normalized binary exponent, and a sign bit. This format for floating point numbers is called IEEE-754.


Try this in your PLC

  --------------+-ADD---------+--

                | A      F8:0 |

                |     16777214|

                | B         1 |

                |           1 |

                | DEST   F8:0 |

                +-------------+

  

Preset F8:0 to 16777214. It will increment once to 16777215, and then it won't increment any more, no matter how many times you execute the rung, and you may rest assured that the ADD instruciton is being executed.

The question is, do you understand why?

Next try manually entering the value 0.2 into F8:1. What happened? Do you understand why the value .2 cannot be represented exactly in a 32 bit floating point number? Next try the value .01. There are many other values which cannot be represented exactly. This is not a limitation of your PLC, every computer is subject to the same problem, though double floats (64 bit) improve the precision quite a bit.

If you want to take a look at what a floating point number looks like in binary, check out this web page:
http://babbage.cs.qc.edu/IEEE-754/Decimal.html

If you will log into the AB knowledge base at ab.com and search for tech note 18209 you can read all about how floats are stored and handled in your PLC.

Alaric said:

Preset F8:0 to 16777214. It will increment once to 16777215, and then it won't increment any more, no matter how many times you execute the rung, and you may rest assured that the ADD instruciton is being executed.

Click to expand...

OK, so if it is 23 binary digits, then how does it store the 24 digit number 1111 1111 1111 1111 1111 1111 (16777215)?

Alaric said:

Next try manually entering the value 0.2 into F8:1. What happened? Do you understand why the value .2 cannot be represented exactly in a 32 bit floating point number? Next try the value .01. There are many other values which cannot be represented exactly.

Click to expand...

Unfortunately, I don't have the luxury of a test AB PLC. From looking at the conversion it looks like .2 and .01 in FP is the same as trying to divide 2/3 in decimal. It has infinite number of decimal places. Am I right?

If you will refer to the AB tech note I mentioned earlier, you will see that in IEEE-754 format, an implied 1 is used. Thats how the extra bit is squeezed in.

Go to http://babbage.cs.qc.edu/IEEE-754/Decimal.html and enter in 16777215 and click [not rounded]. In the 32 bit float field you will see
0 10010110 (1.) 11111111111111111111111.
Notice that is 33 binary digits. The 1 and the decimal point (shown in red) in front of the 23 bit mantissa is always implied. Try several numbers and see what you get. This web tool always shows that implied 1 and its implied decimal.

You can also learn more about IEEE 754 here: http://en.wikipedia.org/wiki/IEEE_754

Unfortunately, I don't have the luxury of a test AB PLC. From looking at the conversion it looks like .2 and .01 in FP is the same as trying to divide 2/3 in decimal. It has infinite number of decimal places. Am I right?

Click to expand...

Each of the digits in the mantissa represents a binary fraction. that is 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, etc. Bits are selected to most closely approximate the floating point number, but there are an infinite number of numbers that cannot be exactly represented in this manner. The closest you can get to 0.1 is 9.9999994e-2. The closest you can get to .2 is 1.9999999e-1 and the closest you can get to .01 is 9.9999998e-3

See..this is why humans ultimately chose a base 10 system.

So then getting back to the OP questions, the data logging configuration is probably just not set up to deal with the conversion of a floating point word beacuse it is not, in fact, just "a 32 bit number". It required interpretation that is not built in to the data logger.

Thank you for your thoroughness Alaric. I have not had to deal with floating point numbers as of yet, but I know what to look out for now. Luckily, real world processes don't frequently deal with numbers that precise or large. At least that can't be scaled anyway.

jedft said:

See..this is why humans ultimately chose a base 10 system.

Click to expand...

Had we chosen a base 6 system, kids would be able to add easier and you could count to 35 on your fingers.

Even in base 10 there are numbers that cannot be represented exactly. But it is what it is and it ain't changing.

Ok Technote ID 25075 says to use a long integer instead of a float for Data logging.