CompactLogix UINT32 to Real

I am running a test with a CompactLogix and 1769 DeviceNet card.
My problem is that I’m trying to read values back from a device which stores the process values as a UINT32 value. My understanding is that the CompactLogix will treat the input data as all SINT values when used with a DeviceNet card. To convert the values to a real seems to be quite in-depth, plus the fact that my UINT32 process values can go negative.

Does anyone have a simple way of doing the covert ion.

Many thanks

First of all, if the value is a UINT32 (a 32-bit UNSIGNED integer) it won't go negative. However, if it is a SIGNED 32-bit integer you are in luck. The DINT data type in the CPLX is a 32-bit signed type.

You can use a synchronous copy instruction (CPS) to combine four continuous SINT values into a single DINT. Put the first SINT of the four as the source tag, the DINT you want the value in as the destination and the length as 1. Voila, you have your DINT value.

My statement above assumes that the data really is coming across as a DINT. If is is and you are talking about displaying it as a REAL then it must be a formatted DINT, that is there is an assumed decimal place in the data. If this is the case simply divide the DINT by the appropriate power of 10 with the destination as a REAL and you should be good.

It is also possible that the data is already coming across as a REAL. This is even easier. In the example above where I talk about the CPS instruction, just use a data type REAL as the destination data type and the bit pattern will be placed in the REAL tag ready ofr display.

Keith

The I/O image of a 1769-SDN is a 90-element array of DINT elements, so if the data is a Signed 32-bit Integer it's already going to be in a usable format.

What is the device you are interfacing with ?

One issue you may still run into is if the data block layout mixes 16 and 32 bit words in the data block without making sure the 32-bit words fall on a double word boundry. For example, if the block starts with a 16-bit status word followed by a 32-bit process value the process value may straddle a DINT boundry in your data group.

You need to know what your data group layout is as well as how that data group maps into the data block you get from the DeviceNet scanner.

Keith

Thanks Keith

The value being read is an unsigned 32 bit value.
As the value is handled as signed by the Compactlogix I naturally reach 32767 and then have to handle the sign bit.

I'll take a further look.
Mark

ControlLogix has no unsigned data formats.

DINT values range from -2,147,483,648 to +2,147,483,647
INT values range from -32768 to +32767
SINT values range from -128 to +127

If your data is coming in as a 32-bit Unsigned integer, as long as it is less than 2,147,483,648 it will not "go negative".

HI Guys
Firstly thanks for you replies, I’m not an expert on AB so I appreciate your help.

The product by the way is a Siemens BW500 weighing integrator.
I have made some progress by using the following code.
Sorry guys I don’t know how to upload an image into my reply.

I used the copy function (COP) to move (length of 9)from Local2:I.data[0] to my destination read_block[0], my read_block is defined at INT.

Read_data[0] is a status word, ignore this
read_data[1] is my LSW for my rate process value
read_data[2] is my MSW for my rate process value

to get my actual value as RATE (defined as REAL) I look at the MSW, if it is >0 read_block[1]>65536 + read_block[2]/1000

If the value read_block[2] <0
read_block[1]*65536 + 65536 + read_block[1]/1000

This seems to work but if my MSW changes it’s sign bit the value will be incorrect, for the RATE value this will be OK as long as the RATE does not exceed something like 13 Million, not likely to happen as this is a belt scale.

The problem will occur on the totaliser because the value could potentially reach 100 millon.

Thanks again guys
Mark

Let me see if I understand you.

You have a device that is returning a floating point value over devicenet and that floating point value is tansmitted as a 32 bit integer over devicenet. Is that correct?

If that is the case then this is not an uncommon problem and the solution is surprisingly simple. The IEEE-754 floating point bit is pattern is preserved in the DINT - all you need to do is get that pattern bit for bit into a floating point data tag. The COP instruction is the way to do this. It will copy bit for bit and not apply any conversion.

Lets say for example your device transmits a value of 15.5 to the PLC. It will transmit 01000001011110000000000000000000. The PLC receives that in a 32 bit integer, which looks like the integer 68648960 to the PLC, however its the exact same bit pattern as 15.5 if it were a float.

COP DINT_TAG FLOAT_TAG 1 will move that pattern bit for bit to the float and give you 15.5

Hope that helps.

So, it sounds like you have a 32-bit unsigned integer coming back. It looks like it is pre-formatted in units * 1000, which is why you are dividing at the end. You have broken the DNET block down into manageable parts with the first COP so you can ignore the status word and get re-aligned.

As an immediate aside I would change the copy from the input image to the internal read block to a synchronous copy or at some point you WILL end up with mismatched LSW and MSW values. With the Logix platform the image table updates are asynchronous to the plc scan. After the input image to internal data copy you can use the standared COP.

The next thing i would do is a COP with Source of read_data[1], destination of an internal DINT and a length of 1. That will put the bit pattern in read_data[1] and read_data[2] into a DINT with read_data[2] as the MSW. That all by itself will get you up to 2 million units without having to do anything. From here you can divide by 1000 to get your real.

If you really think you will be dealing with more than 2 million units you will need to give up precision and handle the extra using REALs. After the COP to the DINT, do a divide by 1000 and dump it in a REAL. If bit 31 of the DINT is set then add the REAL to 4294967.296. Since the CLX processor only maintains 7 digits of precision you will lose some of those digits but that will be as close as you can get.

But keep in mind that the bit pattern is correct in the DINT for the number you have. So if you are displaying this on an HMI that supports 32-bit unsigned integers just real the number as an unsigned integer and stick a fixed decimal point in the display and you are good to go.

Keith

Hi Keith

Thanks for the explanation, I will make the changes you suggested.

Thanks
Mark

Going back to Alaric's post and your post just before it, you need to be very careful about the data type you believe is being sent. In several locations you have said that the data is an unsigned 32-bit integer. Then in post 7 you say the RATE data is a REAL. So are you dealing with both? If so, the basic idea is the same but the destination data type is different. If it truly is an IEEE 754 floating point number then Alaric's post is the one to follow. If it is really a 32-bit integer with an implied decimal point, then my description will work. But generally speaking I wouldn't consider an integer with an implied decimal point a REAL. I would consider it an integer with an implied decimal point.

Keith

Uint32 values

HI Keith

Just to clear up, the value from the integrator is an Unsigned int of 32 bits.

I made a tag of type REAL because I assumed that once I set my destination in the compute function to point to my RATE tag the value would take on the REAL format.

I have assumed this, not being an AB expert.

Mark

Alaric said:

Lets say for example your device transmits a value of 15.5 to the PLC. It will transmit 01000001011110000000000000000000. The PLC receives that in a 32 bit integer, which looks like the integer 68648960 to the PLC, however its the exact same bit pattern as 15.5 if it were a float.

COP DINT_TAG FLOAT_TAG 1 will move that pattern bit for bit to the float and give you 15.5

Hope that helps.

Click to expand...

Just follow alaric´s recommendation and that´s all.