Unable to read register values from Modbus TCP server

[dhoney]

I have an HMI panel that is Modbus TCP master, my device is Modbus TCP slave.

HMI-master(10.0.0.1)---ethernet-->Device-slave(10.0.0.2:502)

When I run the server I can see transactions in the debug log, tcpdump even shows me interactions happening with the two clients.

However, when I try to connect to the Server locally on the same device with a separate script, I do not get the updated values.

The connection to the HMI was tested as working on a windows laptop running Modbus Slave so the data path is confirmed.

It's also worth noting that when making modifications to the server with my client test code, I do see those changes take place, but not when trying to get at the HMI's values it's sending over.

I feel I may be missing something fundamental here about how the server operates and maps data blocks to registers but I can't be sure.

If anyone can offer up some advice I'd greatly appreciate it.

A brief snippet of tcpdump.

root@device# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:07:06.623834 IP 10.0.0.1.57102 > 10.0.0.2.502: Flags [P.], seq 2884696980:2884696992, ack 1568911665, win 33580, length 12
16:07:06.924802 IP 10.0.0.1.57102 > 10.0.0.2.502: Flags [P.], seq 12:24, ack 1, win 33580, length 12
16:07:06.974903 IP 10.0.0.1.57090 > 10.0.0.2.502: Flags [FP.], seq 2882294909:2882294957, ack 2982870381, win 33580, length 48
16:07:06.975181 IP 10.0.0.2.502 > 10.0.0.1.57090: Flags [R], seq 2982870381, win 0, length 0
16:07:07.225833 IP 10.0.0.1.57102 > 10.0.0.2.502: Flags [P.], seq 24:36, ack 1, win 33580, length 12
16:07:07.314122 IP 10.0.0.2.502 > 10.0.0.1.57102: Flags [S.], seq 1568911664, ack 2884696968, win 29200, options [mss 1460,nop,nop,sackOK], length 0
16:07:07.314672 IP 10.0.0.1.57102 > 10.0.0.2.502: Flags [.], ack 1, win 33580, length 0
16:07:07.527945 IP 10.0.0.1.57102 > 10.0.0.2.502: Flags [F.], seq 49, ack 1, win 33580, length 0
16:07:07.534481 IP 10.0.0.1.57103 > 10.0.0.2.502: Flags [S], seq 2885027223, win 32768, options [mss 1460,nop,nop,sackOK], length 0
16:07:07.534762 IP 10.0.0.2.502 > 10.0.0.1.57103: Flags [S.], seq 2381535302, ack 2885027224, win 29200, options [mss 1460], length 0
16:07:07.535366 IP 10.0.0.1.57103 > 10.0.0.2.502: Flags [.], ack 1, win 33580, length 0

tcp dump when the server is running

root@device:# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:19:15.854508 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 3097935189:3097935201, ack 3309520655, win 32458, length 12
16:19:15.859986 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 1:50, ack 12, win 29200, length 49
16:19:15.867594 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 12:24, ack 50, win 32409, length 12
16:19:15.871266 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 50:99, ack 24, win 29200, length 49
16:19:15.880512 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 24:36, ack 99, win 32360, length 12
16:19:15.884029 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 99:112, ack 36, win 29200, length 13
16:19:15.891539 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 36:48, ack 112, win 32347, length 12
16:19:15.895015 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 112:123, ack 48, win 29200, length 11
16:19:15.902513 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 48:60, ack 123, win 32336, length 12
16:19:15.906159 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 123:172, ack 60, win 29200, length 49
16:19:15.913526 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 60:72, ack 172, win 32287, length 12
16:19:15.917142 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 172:221, ack 72, win 29200, length 49
16:19:15.926524 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 72:84, ack 221, win 32238, length 12
16:19:15.930067 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 221:234, ack 84, win 29200, length 13
16:19:15.937525 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 84:96, ack 234, win 32225, length 12
16:19:15.940955 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 234:245, ack 96, win 29200, length 11
16:19:15.948512 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 96:108, ack 245, win 32214, length 12
16:19:15.952029 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 245:294, ack 108, win 29200, length 49
16:19:15.959525 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 108:120, ack 294, win 32165, length 12
16:19:15.963076 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 294:343, ack 120, win 29200, length 49
16:19:15.972515 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 120:132, ack 343, win 33580, length 12
16:19:15.976082 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 343:356, ack 132, win 29200, length 13
16:19:15.980579 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 132:144, ack 356, win 33567, length 12
16:19:15.984008 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 356:367, ack 144, win 29200, length 11
16:19:15.991531 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 144:156, ack 367, win 33556, length 12
16:19:15.995115 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 367:416, ack 156, win 29200, length 49
16:19:16.002507 IP 10.0.0.1.58204 > 10.0.0.2.502: Flags [P.], seq 156:168, ack 416, win 33507, length 12
16:19:16.006091 IP 10.0.0.2.502 > 10.0.0.1.58204: Flags [P.], seq 416:465, ack 168, win 29200, length 49

The server debug output

DEBUG:pymodbus.factory:Factory Request[3]
DEBUG:pymodbus.datastore.context:validate[3] 100:20
DEBUG:pymodbus.datastore.context:getValues[3] 100:20
DEBUG:pymodbus.server.sync:send: 46500000002b01032800000000000000000000000000000000000000000000000000000000000000000000000000000000
DEBUG:pymodbus.server.sync:0x46 0xb4 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x9 0x0 0x1
DEBUG:pymodbus.transaction:0x46 0xb4 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x9 0x0 0x1
DEBUG:pymodbus.factory:Factory Request[3]
DEBUG:pymodbus.datastore.context:validate[3] 10:1
DEBUG:pymodbus.datastore.context:getValues[3] 10:1
DEBUG:pymodbus.server.sync:send: 46b4000000050103020000
DEBUG:pymodbus.server.sync:0x47 0x18 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x63 0x0 0x14
DEBUG:pymodbus.transaction:0x47 0x18 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x63 0x0 0x14
DEBUG:pymodbus.factory:Factory Request[3]
DEBUG:pymodbus.datastore.context:validate[3] 100:20
DEBUG:pymodbus.datastore.context:getValues[3] 100:20
DEBUG:pymodbus.server.sync:send: 47180000002b01032800000000000000000000000000000000000000000000000000000000000000000000000000000000
DEBUG:pymodbus.server.sync:0x47 0x7c 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x9 0x0 0x1
DEBUG:pymodbus.transaction:0x47 0x7c 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x9 0x0 0x1
DEBUG:pymodbus.factory:Factory Request[3]
DEBUG:pymodbus.datastore.context:validate[3] 10:1
DEBUG:pymodbus.datastore.context:getValues[3] 10:1
DEBUG:pymodbus.server.sync:send: 477c000000050103020000
DEBUG:pymodbus.server.sync:0x47 0xe0 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x63 0x0 0x14
DEBUG:pymodbus.transaction:0x47 0xe0 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x63 0x0 0x14
DEBUG:pymodbus.factory:Factory Request[3]
DEBUG:pymodbus.datastore.context:validate[3] 100:20

The server code, modified from here :
https://github.com/riptideio/pymodbus/blob/master/examples/common/modbus-payload-server.py

#!/usr/bin/env python
#---------------------------------------------------------------------------#
# import the various server implementations
#---------------------------------------------------------------------------#
from pymodbus.server.sync import StartTcpServer

from pymodbus.device import ModbusDeviceIdentification
from pymodbus.datastore import ModbusSequentialDataBlock
from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext

#---------------------------------------------------------------------------#
# import the payload builder
#---------------------------------------------------------------------------#

from pymodbus.constants import Endian
from pymodbus.payload import BinaryPayloadDecoder
from pymodbus.payload import BinaryPayloadBuilder

#---------------------------------------------------------------------------#
# configure the service logging
#---------------------------------------------------------------------------#
import logging
logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)

#---------------------------------------------------------------------------#
# Here we use the same reference block for each underlying store.
#---------------------------------------------------------------------------#

store = ModbusSlaveContext(
    di = ModbusSequentialDataBlock(0, [0]*10),
    co = ModbusSequentialDataBlock(0, [0]*10),
    hr = ModbusSequentialDataBlock(0, [0]*220),
    ir = ModbusSequentialDataBlock(0, [0]*250)
    )
context = ModbusServerContext(slaves=store, single=True)

#---------------------------------------------------------------------------#
# initialize the server information
#---------------------------------------------------------------------------#
# If you don't set this or any fields, they are defaulted to empty strings.
#---------------------------------------------------------------------------#
identity = ModbusDeviceIdentification()
identity.VendorName  = 'Pymodbus'
identity.ProductCode = 'PM'
identity.VendorUrl   = 'http://github.com/bashwork/pymodbus/'
identity.ProductName = 'Pymodbus Server'
identity.ModelName   = 'Pymodbus Server'
identity.MajorMinorRevision = '1.0'

#---------------------------------------------------------------------------#
# run the server you want
#---------------------------------------------------------------------------#
StartTcpServer(context, identity=identity, address=("10.0.0.2", 502))

The client test code (also running on the same machine as the server):
I use this to verify the registers set up by the Server are getting written to by the HMI.
When I run it I cannot find the values that the HMI is supposed to be writing to the server.

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

client = ModbusClient("10.0.0.2", port=502)

for x in xrange(200):
    r = client.read_holding_registers(x)
    print vars(r)

The variable mappings on the HMI

PROFILE	40100
RATE	40005
CIN	40003
LBS/FT	40004
COLOR	40200
CIN2	40006
RATE2	40001
2LBS/FT	40008
TRIGGER	40010

[dhoney]

Some more verbose tcp dump data, I can see there is a message from the slave claiming the checksum is incorrect.

    10.0.0.2.502 > 10.0.0.1.58450: Flags [P.], cksum 0x144e (incorrect -> 0x8bc2), seq 2501:2550, ack 996, win 29200, length 49
17:05:37.211962 IP (tos 0x0, ttl 128, id 48976, offset 0, flags [DF], proto TCP (6), length 52)
    10.0.0.1.58450 > 10.0.0.2.502: Flags [P.], cksum 0xa304 (correct), seq 996:1008, ack 2550, win 33409, length 12
17:05:37.216162 IP (tos 0x0, ttl 64, id 8081, offset 0, flags [DF], proto TCP (6), length 53)
    10.0.0.2.502 > 10.0.0.1.58450: Flags [P.], cksum 0x142a (incorrect -> 0xaf69), seq 2550:2563, ack 1008, win 29200, length 13
17:05:37.223946 IP (tos 0x0, ttl 128, id 48977, offset 0, flags [DF], proto TCP (6), length 52)
    10.0.0.1.58450 > 10.0.0.2.502: Flags [P.], cksum 0xa28c (correct), seq 1008:1020, ack 2563, win 33396, length 12```

[dhoomakethu]

what is the output of the client transactions? Do you get any errors ? Please share the client logs as well.

[dhoney]

@dhoomakethu I only have logs from my device (the Modbus TCP Slave) posted above.
On Monday I may be able to get a look at the program loaded onto the HMI but I don't have access to the physical device at this time.

Regarding this section in my server code:

store = ModbusSlaveContext(
    di = ModbusSequentialDataBlock(0, [0]*10),
    co = ModbusSequentialDataBlock(0, [0]*10),
    hr = ModbusSequentialDataBlock(0, [0]*220),
    ir = ModbusSequentialDataBlock(0, [0]*250)
    )
context = ModbusServerContext(slaves=store, single=True)

For holding and input registers, will this create 220 and 250 registers on the corresponding ranges (3xxxx and 4xxxx) or is there something more?

Some of the values being sent over are strings, ints, and floats, is there more that I need to do to the ModbusSlaveContext to account for the incoming data types from the Master (HMI) or this that configuration satisfactory?

[dhoomakethu]

Yes, a statement like hr = ModbusSequentialDataBlock(0, [0]*220), would create a register range starting at index 0 ==> 40001 for holding registers and all the way up to 40221 as per the modbus addressing convention. So any read on address 0 would give you the values stored at 40001. A very good explanantion of various datablocks are available here , please go through the comments.

[dhoomakethu]

re. your second question (different values being sent) you can use the BinaryPayloadBuilder class to build your server data and BinaryPayloadDecoder to decode back the data with your client. refer

[dhoney]

Reviewing the section on datablocks confirms to me the layout of registers is correct.

The BinaryPayloadDecoder is quite nice, I've been using python's struct module to handle floats and the like but this will a nicer way to deal with string values.

My main concern regarding the incoming data types was if they were being rejected based on a dependency for further configuration. This does not seem to to be the case since the holding and input registers take 16 bit values and don't care if it's an int, float, or string.

It seems for me next steps are to look at the configuration of the client (HMI) and see if I can glean any additional information from that, the manual itself, or tech support.

[dhoomakethu]

Let me understand the problem here correctly, which communication is broken, HMI-> PyModbusServer or PyModbusServer->PyModbusClient ?

[dhoney]

The communication path for HMI->PyModbusServer is broken.

I use a test program to read from the PyModbusServer (below) to see if the registers are being written to but their values do not change from their initial value (in this case 0).

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

client = ModbusClient("10.0.0.2", port=502)

for x in xrange(220):
    r = client.read_holding_registers(x)
    print vars(r)

[dhoomakethu]

What is the device address the HMI is trying to read the value from ? The server you have created is having the device address as zero so it will only respond to broadcasts, if you want to create a server with particular device address (let's say 1) set context = ModbusServerContext(slaves={1: store}, single=False). Also if both master and slave are on the same subnet use 0.0.0.0 in your StartTcpServer i.e StartTcpServer(context, identity=identity, address=("0.0.0.0", 502)). Let me know if this solves your issue.

[dhoney]

The HMI is configured to talk to address 1.

I made the suggested changes but now when I run my code to instead of empty/unchanged registers I get 'exception_code': 11.

Looking at the modbus spec this indicates the device is unreachable or failed to respond.

Is there a way from the client to explicitly say "connect to 0.0.0.0 at slave address 1"?
I noticed the source_address argument and tried client = ModbusClient("0.0.0.0", port=502, source_address=('',1)) but still got the same exception code.

Update: setting unit=1 fixes the exception code 11 issue, but i still get empty register values

    r = client.read_holding_registers(x, unit=1)
    r = client.read_input_registers(x, unit=1)

[dhoomakethu]

For the client it is better to use explicit IP address instead of 0.0.0.0. is there a firewall that is active and blocking the transactions? Also if it is possible to use a different port,use a port >1024 like 5020 and check.

[dhoney]

I have tested using both 0.0.0.0 and the assigned static IP.

To my knowledge there is no firewall, it is a direct connection.
At this time I cannot specify another port without sending the client some updated code.

I have ordered a duplicate HMI that should be in tomorrow, once I replicate the setup in my lab I will have more information to share.

[dhoomakethu]

Please share the details of your HMI client (model/spec) etc