INT Conversion

Udunit

Lifetime Supporting Member
Join Date
Mar 2014
Location
Woodstock, Ontario
Posts
33
I have a Controllogix program that the programmer used modbus to send scale data to the PLC. We recently replaced a piece of equipment on this and I need to convert INT data to a real number. This will only be a display weight on the HMI and now control. As an example, 32767 to the PLC represents 327.67 KG's. However, when it goes to negative this continues to add the weight. Will a COP instruction do this conversion for me? IE, when I get tto -32768 the COP will make this 65535? I'm going in remote now so I want to get it right for them. Thanks,
 
My understanding is you are reading an unsigned integer from a scale and need to deal with when the last bit is used? The COP instruction blindly copies bit for bit, so it will not work for converting from a INT to a REAL. You will get a random looking number because some of the bits are the base number and the rest is an exponent. The newest family of Controllogix processors have support for UINT data types, so if you happen to be using one of those processors, take advantage of that. If you do not have that option, you can COPy the unsigned integer into a DINT. That would make the bit 31 the sign bit, and the first 16 bits would be treated normally. You could then scale that DINT to a REAL to move your decimal place for your display.
 
I can use the UINT. Can I copy or move the int to the uint then? This is a really poorly written program that I inherited and the programmer has done some strange things. I'm slowly trying to clean it up.
 
You might be able to COP the INT to a DINT and preserve the bit pattern and not have to worry about going negative until your scale hits 21474836.47 Kg. Then DIVide the DINT by 100 to get a Real number if so desired.
 
In order to make it unsigned, you will need to test the INT value. If GEQ zero, move to a DINT. If LES zero, add 65536 to the INT value into the destination DINT. Then divide the (unsigned) DINT by 100.0 into the scaled REAL result.
 
Helliana and OkiePC have both suggested COPy .....

That is incorrect.

To perform data conversion from an INT to a DINT, you must use MOV.
 
MOV instruction does a data type conversion. I haven't tested to verify if MOV is considered a logical instruction or not to see if converts using the zero-fill or sign-extension method.


COP does bit by bit conversion so you don't have to worry about the conversion..
 
MOV instruction does a data type conversion. I haven't tested to verify if MOV is considered a logical instruction or not to see if converts using the zero-fill or sign-extension method.


COP does bit by bit conversion so you don't have to worry about the conversion..

YOU CANNOT USE COP !

COP does NO conversion !

The source and destination data-types must be the same.

If you use COP to copy into a DINT (4 bytes), then 4 bytes will be copied from the source, which is only 2 bytes long.

2 bytes will be pulled from whatever follows the INT in memory.

2021-04-15_092801.jpg
 
MOV will not work because it will do a data type conversion, and the number will still be negative.


COP will not work because of the different size of the data types. I thought it would copy the int and ignore the last 16 bits, but i was mistaken. HOWEVER, BTD instruction does do that.


See attached.


wGtT9pAHuTmpQAAAABJRU5ErkJggg==


Uint.PNG
 
MOV will not work because it will do a data type conversion, and the number will still be negative.


COP will not work because of the different size of the data types. I thought it would copy the int and ignore the last 16 bits, but i was mistaken. HOWEVER, BTD instruction does do that.


See attached.


wGtT9pAHuTmpQAAAABJRU5ErkJggg==

+1, I had to do this recently to convert SINT to DINT. BTD works. Unfortunately because of sign-extension, MOV doesn't. Unfortunately because of neighboring memory locations having garbage values, COP doesn't.
 
Last edited:
@daba is right: don't use COP; use MUL instead; correct for the negative 16-bit signed values as needed; see below.

The BTD solution by @PreLC is also correct.

xxx.png


---
Take care of the bits, and the bytes will take care of themselves.
 
Here's what I ended up doing. This was my first thought and it works well. I was seeing if there was an easy instruction to do this. Thanks all for the input!

SCALE WEIGHT.jpg
 
Here's what I ended up doing. This was my first thought and it works well. I was seeing if there was an easy instruction to do this. Thanks all for the input!

What happens when MBTU_MB_3xx[2] equals zero (or one, for that matter)?

And, technically, the result is off by 2 bits when the INT is negative.
 
Last edited:
[Update: second!]

  1. The formula on Rung 26 has a typo:
    1. The first 32767 should be 32769.
    2. Or skip those two integer adds and add 655.36 after the divide.
  2. Neither rung converts a value of 0 or 1
    1. SourceB in the GRT on Rung 25 should be -1.
    2. Although it may not matter for this process and the programmed behavior is intentional.
  3. The two rungs can be combined with a branch after the NEQ on Rung 25
    1. There is no need to test that mode integer twice.
 
Last edited:
This is for remote display only. The 2 bit difference is so little as far as the display goes it's not an issue. The actual filling controls is direct hard contacts from the scale. It's a very messy program that I inherited from the Italian company that provided the filler. I don't believe they had any AB experience at all based on what I see in the program.
 

Similar Topics

Im trying to use a MSG instruction to get the serial numbers of all addon cards and display the serials on a HMI interface. I have the logic done...
Replies
2
Views
521
Hello, I am having some trouble converting my Elapsed Time from TIME data type to INT data type so that I can display it on my HMI. While I can...
Replies
6
Views
1,675
Long time viewer, first time poster. First I want to start, yes I know, PLC-2 and PLC-5 do not belong in manufacturing plants anymore, but...
Replies
5
Views
2,056
Hello, I'm taking in two 16 bit ints from the field via modbus, one low order and one high order to combine into their proper 32-bit form. I've...
Replies
1
Views
1,250
I have been working on an existing project for some time now and restructured the whole program into POUs instead of a singular main. Everything...
Replies
18
Views
3,188
Back
Top Bottom