N: F: L: COP MOV CPW etc...

I know this has been brought up before and I have read through many posts and tried many different things before asking...
I am using a ML1400 Ser B.
The application I have running sends a Modbus message to a scale head to find out the weight. The message results are stored in N12:60 for 4 elements.
Then taking N12:63 and moving it to N7:3, leaving the rest behind. Somehow this seems to get around the 32767 limitation and it reads instead in Hex format and does not fault out with an overflow error.
However I want to take 3 of these readings, combine them and put them into another register (N15:30) so I can send this information to a server piece.
No matter how I try to do this it will not work or be accurate.
I have tried the following:
ADD N16:3 and N16:4 result into F8:1
ADD F8:1 and N16:19 result into F8:2
MOV F8:2 into L22:0
CPW L22:0 into N21:0 (for testing purposes) length of 2.
Result I get is N21:0 is not the number or even close and N21:1 is 1

I'm sure there's plenty more information needed but I thought you could have a look and see if we can get the ball rolling on how to solve this.

Issue is it is for a scale that reads up to 65,000 lbs. I wand to combine 3 of them and report the total number.

Maybe it's just me, but I'm having a hard time tracking with you. For the sake of simplicity:

1. What format does the scale weight data come into the PLC (signed integer, unsigned integer, BCD, etc.)?
2. How many bytes/bits make up the scale weight data?
3. If you transpose the data bit for bit into a long integer (using say a BTD), does the data display the correct weight?
4. Are you saying you want to take three readings from the same scale and then find the average weight?

Take a big step back and look at the N12:60-63 elements in Hex format, and consider what they're supposed to represent.

This is a very common problem when Floating-Point data is packed into Modbus memory registers.

CPW and maybe BTD or SWP are going to help you solve the problem, but let's figure out what's supposed to be there (and the hex values) first.

Ken Roach said:

Take a big step back and look at the N12:60-63 elements in Hex format, and consider what they're supposed to represent.

This is a very common problem when Floating-Point data is packed into Modbus memory registers.

CPW and maybe BTD or SWP are going to help you solve the problem, but let's figure out what's supposed to be there (and the hex values) first.

Click to expand...

Ok, in Hex format they are as follows:
N12:60=0 N12:61=19 N12:62=0 N12:63=561D

RonJohn said:

Maybe it's just me, but I'm having a hard time tracking with you. For the sake of simplicity:

1. What format does the scale weight data come into the PLC (signed integer, unsigned integer, BCD, etc.)?
2. How many bytes/bits make up the scale weight data?
3. If you transpose the data bit for bit into a long integer (using say a BTD), does the data display the correct weight?
4. Are you saying you want to take three readings from the same scale and then find the average weight?

Click to expand...

Negative. What I need to do is take the reading that is coming in via Modbus and add 3 separate scales, total them up and report that number in an integer to send to the server.

A little more specifically what my problem is...
I have 3 different PLC's getting weight information from the scales via Modbus TCP. This is being put into registers and the weight is being taken from them and transferred to another PLC which then transfers all that information to yet 2 more. I need to take 3 of those weights at the end and combine them into 1 total weight.
The message already in place is using N registers to send data in a MSG to the server. I just need my total number in one of those existing N registers already going to the server.

Nhrafan26 said:

Negative. What I need to do is take the reading that is coming in via Modbus and add 3 separate scales, total them up and report that number in an integer to send to the server.

Click to expand...

OK, so your weight comes in two words (word 3 = MSW, Word 4 = LSW per your attachment). If you copy those two words into a Long integer, you should get the weight in one register. If the value is incorrect, you will need to do some byte swapping to get the right value.

I'm not real familiar with MicroLogix but it seems to me like you'd be best suited doing your addition in L registers as this won't involve any more manipulation than what's mentioned above.

Nhrafan26 said:

I need to take 3 of those weights at the end and combine them into 1 total weight.

Click to expand...

Can you use L registers for this? Sounds like this would be the most straight forward since the total weight could be > 65536.

Nhrafan26 said:

The message already in place is using N registers to send data in a MSG to the server. I just need my total number in one of those existing N registers already going to the server.

Click to expand...

How are you going to put a number > 65536 into ONE N register? If you're willing to sacrifice resolution, you could store the weight in 10's, 100's, or 1,000's. of pounds.

RonJohn said:

Can you use L registers for this? Sounds like this would be the most straight forward since the total weight could be > 65536.


How are you going to put a number > 65536 into ONE N register? If you're willing to sacrifice resolution, you could store the weight in 10's, 100's, or 1,000's. of pounds.

Click to expand...

This is what I'm trying to understand myself.

First problem I have is that the scale data is being input in an N register, well 4 of them to be exact but then the weight is being taken from one register and moved to another. HOW though is that value being represented as a Hex value and not a decimal value right away in the table?? I just tried writing the EXACT same message on another ML1400 on the system and it instantly puts the values as a decimal value into the tables. If I can work with Hex values instead it's not a problem.
I am trying to figure out how they did it to begin with.

Provide some sample data and we can figure it out. Several examples of:
This is what the scale says, and this is what the 4 registers in the PLC say.

mellis said:

Provide some sample data and we can figure it out. Several examples of:
This is what the scale says, and this is what the 4 registers in the PLC say.

Click to expand...

This is what I provided before:

Ok, in Hex format they are as follows:
N12:60=0 N12:61=19 N12:62=0 N12:63=561D

Along with this the scale reads: 22045 at this point.

0x561D hex = 22045 decimal, so the data is coming in as an ordinary integer instead of a floating-point value.

Do you know if the datatype is supposed to be a 32-bit signed or unsigned integer (spread across N12:62 and N12:63) or a 16-bit unsigned integer (in N12:63 only) or a 16-bit signed integer (in N12:63 only) ?

The easiest thing to do, I think, would be to use a CPW instruction to move the hex data unmodified from N12:62 and N12:63 to a single L-type Long Integer register.

You can then do the addition and averaging with the Long datatype.

Ken Roach said:

0x561D hex = 22045 decimal, so the data is coming in as an ordinary integer instead of a floating-point value.

Do you know if the datatype is supposed to be a 32-bit signed or unsigned integer (spread across N12:62 and N12:63) or a 16-bit unsigned integer (in N12:63 only) or a 16-bit signed integer (in N12:63 only) ?

The easiest thing to do, I think, would be to use a CPW instruction to move the hex data unmodified from N12:62 and N12:63 to a single L-type Long Integer register.

You can then do the addition and averaging with the Long datatype.

Click to expand...

It's all pretty easy to do with Long or floating point, what I'm trying to figure out is how they did it all in N files and how to duplicate that process.

You need to figure out the datatype for certain. As I described, it's probably either a 32-bit signed integer or a 16-bit unsigned integer.

You can do that either by reading their documentation, or by increasing the transmitted value to larger than 32767 to see what the equivalent hex values in the two adjacent registers are.

I recommend against devising some sort of 16-bit unsigned integer workaround unless it's entirely necessary: a person who works on the system after you might not want to reverse engineer your workaround.