Hex addition in RSLogix 5000 not working as expected?

I am trying to concatenate 3 hex numbers into 1, and I am doing this as follows:

3 registers with 8 bit values in them need to be joined into 1 number

Least significant register: 99
2nd Register: 99
Most significant register: 9

9 x 10000 = 90000 +
99 x 100 = 9900
99 x 1 = 99

Ans = 99999

Doing these multiplcations on RSLogix 5000 using "16#" before the number for both that being multiplied and the multiplier produce the correct results, but adding these results is not working as expected.

Adding 9900 + 99 = 9899 on RSLogix
Adding 90000 + 9899 = 89899 on RSLogix

Anyone know what could be happening?

An important thing to point out is that the data is being received from a meter, and as decimals are showing up as "-103" which using the "Hex" style from the dropdown menu results in 0x99

Thank you
Patrick

What is the data type of the tags being used?
Could be rounding errors caused by using reals.

Let's start at the form in which you are receiving the data. Apparently it is 3 SINT values with each one being encoded in BCD. 'Hex' is just a method of display of a normally encoded number. The problem is, these have BCD encoding. A clue to BCD is, when viewing as 'hex', you never see the letters a-f during counting.

Create three other SINT registers. I'll refer to these as S1 (for the most significant) S2 and S3. Then execute the FRD instruction Converting From BCD) three times, with the source being one of your received registers and the destination being the appropriate new register.

Then perform a Compute (CPT) instruction with the destination being a DINT. The expression will be ((S1 * 10000) + (S2 * 100) + S3). This should give you the full value in your destination DINT.

bernie_carlton said:

Let's start at the form in which you are receiving the data. Apparently it is 3 SINT values with each one being encoded in BCD. 'Hex' is just a method of display of a normally encoded number. The problem is, these have BCD encoding. A clue to BCD is, when viewing as 'hex', you never see the letters a-f during counting.

Create three other SINT registers. I'll refer to these as S1 (for the most significant) S2 and S3. Then execute the FRD instruction Converting From BCD) three times, with the source being one of your received registers and the destination being the appropriate new register.

Then perform a Compute (CPT) instruction with the destination being a DINT. The expression will be ((S1 * 10000) + (S2 * 100) + S3). This should give you the full value in your destination DINT.

Click to expand...

I will try this out thank you!

EDIT:
Using the FRD block resulted in the value of "-103" decimal being converted to 0x63. This value should be 0x99 though (I am using results in real life to know the expected answer of the computation)

Is this meant to happen and what kind of conversion is the 0x99 a result of?

Thank you

Greetings keristos ...

what kind of conversion is the 0x99 a result of?

Click to expand...

based on what you've posted, I think that a lot of your confusion is being caused by Allen-Bradley's insistence on considering the MSB (left-most) bit to always be a (NEGATIVE) sign-bit ...

here's a "boot camp" trick that might be helpful ...

open a tag window ... then click Window > New Window from the RSLogix5000 top menu to open some additional windows ...

then set the Style of each window to show (side-by-side) the results of your operations ...

this is a handy "learning tool" that can help you see (in real-time) how these types of conversions are being done – and equally important – how the results are displayed on the ladder window ...

take a look at the results of using an FRD (From BCD) instruction on the -103 value that you mentioned earlier ...

now go on to the next post ...

.

here we see the results of using a COP (Copy) instruction instead ...

basically we have the binary bit pattern 1001_1001 coming IN to a SINT ... the ladder would display this as -103 ... but ... the COP instruction doesn't display values ...

then we have the binary bit pattern 1001_1001 going OUT to another SINT ... displaying this as a Hex value gives 99 ...

is this the result that you want? ...

the value of "-103" decimal ... ... should be 0x99

Click to expand...

if this solves your problem, the "secret handshake" is that the COP (Copy) instruction moves BIT PATTERNS (ones and zeros) from one location to another ... take a look at the values for My_SINT_Input and for My_SINT_Output in the far right window ... displayed as Binary patterns – they are the same ...

when displayed as a Hex number (in the lower left window) the value of My_SINT_Output appears as 99 – which I THINK is what you're looking for ...

note that if this doesn't fully answer your questions, consider giving the forum a list of sample INPUTS and desired OUTPUTS and we'll help you nail this down ...

the more detail that you provide (ESPECIALLY SAMPLES) then the more detailed we can make our answers ...

good luck with your project ...

.

With the time difference it is difficult to arrive at a solution with just single question/answer exchanges. So I will present a number of questions.

An important thing to point out is that the data is being received from a meter, and as decimals are showing up as "-103" which using the "Hex" style from the dropdown menu results in 0x99

Click to expand...

When you view the value (-103) in "Hex" as 0x99 is that what you EXPECT to see? Are you interpreting this as one less than the decimal value of 100? But the HEX value 0x99 is equal to the decimal value 153. If the registers always appear, when viewed in "hex" as 00 - 99 (without any of the letters A - F) then you are viewing BCD encoding. If that is clear then I have another question.

What do you want to do with this data? Let's ignore the apparent failure, in your mind, of 'hex addition'. Given the three registers do you want to end up with a DINT with a value, when viewed in "hex" of 0x99999? (This would have a decimal value of 629145.) If achieving the concatenated value is what you want then we can help.

But do you want to end up with a DINT containing the decimal value of 99999? If so then use the FRD (three times) followed by the CPT instruction as I specified.

Please clarify exactly what you are seeing and what you want in the end.

Thank you all for your replies, there was a misunderstanding on my behalf.

The register the FRD block was writing was set to HEX and as "-103" was being converted it was resulting in 0x63, when in reality this is the correct value, in decimal form (99)!

Eventually I had to concatenate then yes, and I did this by multiplying by 1, 10 and 100 for the respective bytes.

Thank you for your help,
Patrick

I am glad we could help.