Modbus rtu - reading multiple registers

naturephoenix

Member
Join Date
Jan 2015
Location
Vienn
Posts
181
Hello,

I'm able to read data from the slave with my master s7-1200 PLC.

Now my task is to read multiple registers with address as follows:
(Modbus RTU Register (1-based))
1033
1065
1097
1129
1161
1277
1382
1478
1542
2109
2133
3049
4011
4013
4015
4017
4188
4192
4424
4426
4428
4430
4432
4434
4496
5015
5017
5019
5251
5253
5255

For each this register I know data type.

Can you please tell me what's the correct approach in this cases:

I have 2 ideas on my mind:

Option 1:
Inside PLC create huge DB which covers all registers I need and + spares between needed registers. In that case I just need to use once MASTER function inside PLC and point on starting register and take a lot of bytes. Correct me if I am wrong. My baundrate is 9600, so thats 1200 bytes per sec, that is good speed. So reading 200 bytes (even I do need 30) is not such a problem with this speed, or it is?

Option 2:
Create a loop inside SCL, inside I change register number and my DB_Area adress(place where I store data) everytime I get done and no error signal on pisitive edge. On this way for every register I need to call MASTER FC.
Not for every register, lets say for each GROUP, because some of the data I need from Slave are next to each other(Group 1 ->4424 ,4426, 4428, Group 2 ->4011 ,4013 ,4015, 4017


What do you guys do in such a cases? What should I do?
 
The Modbus spec limits Function code 03 to a maximum of 125 (sequential/contiguous) holding registers.

However, the slave might not support that many. There are slaves that state that they will reply with a fewer number. Sometimes there's no documented statement, you just discover what the maximum is when the request for 125 fails, 124 fails, 123 fails, 120 fails, 110 fails until you get to 64 and that works.

So a group would be limited to whatever maximum your slave supports.

Even if the master supports 125 registers, the first group would be limited to 1033 through 1129, because 1161 is beyond the 125 limit when starting at 1033.

You've got 31 values, some are grouped close to each other, like 4011 - 4017 (qty 4); 4424 - 4434 (qty 6), 5015-5019 (qty 3), 5251-5255 (qty 3), 4188 -4192 (qty 2). I'd probably do those 5 groups as group reads and the remaining 13 as individual read value read transactions.

The data appears to be 32 bit floating point or long integers because the sequential registers increment by two.

A read request message (regardless of how many register are being requested) takes an 8 byte request message.

The reply message has an overhead of 5 bytes plus 2 bytes for every register or 4 bytes for every dual register floating point or long integer.

And there is a 3.5 character silent period after the message to indicate end of transmission. At 9600 baud, that is 4mS.

The unknown is how quickly the field device responds. It varies from device to device. Were the reply instaneous, then a request/reply for one dual register would be 8 + 3.5 + 9 + 3.5 = 24 (11 bit) bytes. So requesting dual register values that are 12 or fewer registers apart would be more efficient that doing another 'read-reply' transaction if the reply were instantaneous. Any delay in the response increases the number 12. The only way to tell what this is however is to test it and measure
 
The Modbus spec limits Function code 03 to a maximum of 125 (sequential/contiguous) holding registers.

However, the slave might not support that many. There are slaves that state that they will reply with a fewer number. Sometimes there's no documented statement, you just discover what the maximum is when the request for 125 fails, 124 fails, 123 fails, 120 fails, 110 fails until you get to 64 and that works.

So a group would be limited to whatever maximum your slave supports.

Even if the master supports 125 registers, the first group would be limited to 1033 through 1129, because 1161 is beyond the 125 limit when starting at 1033.

You've got 31 values, some are grouped close to each other, like 4011 - 4017 (qty 4); 4424 - 4434 (qty 6), 5015-5019 (qty 3), 5251-5255 (qty 3), 4188 -4192 (qty 2). I'd probably do those 5 groups as group reads and the remaining 13 as individual read value read transactions.

The data appears to be 32 bit floating point or long integers because the sequential registers increment by two.

A read request message (regardless of how many register are being requested) takes an 8 byte request message.

The reply message has an overhead of 5 bytes plus 2 bytes for every register or 4 bytes for every dual register floating point or long integer.

And there is a 3.5 character silent period after the message to indicate end of transmission. At 9600 baud, that is 4mS.

The unknown is how quickly the field device responds. It varies from device to device. Were the reply instaneous, then a request/reply for one dual register would be 8 + 3.5 + 9 + 3.5 = 24 (11 bit) bytes. So requesting dual register values that are 12 or fewer registers apart would be more efficient that doing another 'read-reply' transaction if the reply were instantaneous. Any delay in the response increases the number 12. The only way to tell what this is however is to test it and measure

thx man
 

Similar Topics

Dear All, i am trying to connect Danfoss inverter with s7 200 cpu 226.but microwin shows following error at DATA Ptr.i assigned different VB...
Replies
1
Views
38
I'm trying to control a device via MODBUS RTU and the ModbusRtuMasterV2_PcCOM in Twincat 3. I've configured a device with the right com port and...
Replies
6
Views
130
Hi all, Currently having trouble getting a speed reference to write over modbus to an Omron M1... I can successfully write a run command and...
Replies
6
Views
211
Hi, I'm having an issue with a mircologix not transmitting out. The current setup is a mircologix 1400 connected to a Guardian 100 Radio...
Replies
1
Views
108
If a device has Modbus RTU over serial and Modbus RTO over TCP and Modbus TCP then there is a difference between Modbus RTU over TCP vs Modbus TCP...
Replies
7
Views
466
Back
Top Bottom