jconnally
Topic Author
Posts: 2
Joined: 11 Jul 2019, 15:47

Modbus TCP network problem

11 Jul 2019, 16:21

Hello,

Have any TCP/IP networking problems been reported for the RevPiConnect? Specifically, has anyone reported the Pi acknowledging a query for data but never actually responding with the data without the requesting host initiating a TCP Retransmission? I am running a RevPiConnect as a Modbus gateway device and am seeing this issue. A host PC running process control software is on the TCP/IP side of the gateway and a number of RS485 slave devices are on the other side. All slave devices have been independently verified to consistently respond to read/write requests within 20 msec or less without failure.

Attached is a snapshot of data from WireShark running on the PC host. The eth1 interface of the RevPiConnect is configured to have a static IP address of 192.168.0.101. The host PC has static address of 192.168.0.1. This network is local to the PC and RevPi. No other devices exist on the network other than network switches. Beginning at line item 4, the PC host issues a query to the Pi which responds with an acknowledgement [ACK]; however, more than 4 seconds elapse (4.364) without a response which exceeds a timeout in the host PC software. The PC then issues a second query which initiates a TCP Retransmission. After that, the RevPi responds with an acknowledgement [ACK] followed by a duplicate acknowledgement [TCP Dup ACK 8#1], then the response data. This behavior is exhibited somewhat randomly once every 24 to 36 hours and is causing a problem for our host PC control software. Normally, the initial query from the host is immediately (within 50 msec or less) followed by a response from the Pi with valid data. The packet data of the initial query triggering the retransmission has been verified to be a valid Modbus request. Also, the Modbus protocol we are running logs all protocol failures including slave device timeouts to a log file. The log file is clean and shows no errors.

Can anyone provide any explanation for this behavior?

Regards,
JConnally
Attachments
WireShark.png
WireShark.png (176.73 KiB) Viewed 169 times
 
User avatar
dirk
KUNBUS
Posts: 432
Joined: 15 Dec 2016, 13:19

Re: Modbus TCP network problem

17 Jul 2019, 11:33

Dear JConnally, thank you for the detailed description of the error. This helps a lot. I can see some suspicious unit-ids in the Wireshark trace. Which hardware setup do you have and which image do you use?
Please post the /etc/revpi/_config.rsc file and the output of
cat /etc/revpi/os-release
. Can you describe your hardware setup a bit more in detail? I have understood that you use the RevPi Modbus Slave on 192.168.0.101 and a Modbus Master (which?) on 192.168.0.1, richt? Why are there sometimes different unit-ids, i.e. 64 and 1?
 
jconnally
Topic Author
Posts: 2
Joined: 11 Jul 2019, 15:47

Re: Modbus TCP network problem

18 Jul 2019, 23:13

Hi Dirk,

There is no os-release, just image-release. cat /etc/revpi/image-release gives 2018-07-17-revpi-stretch. The config.rsc is attached. The RevPi is used as a TCP to RS485 gateway. The RS485 side has two slave devices with Modbus ID's of 1 and 64 respectively. The value 1 is an RS485 Wago and 64 is a custom realtime board called the "comm board". It's job is to communicate via another RS422 network with a set of brushed motors. The RS485 baudrate is 38400 bit/sec, 8 bits, 1 stop bit, no parity. Overall, we are not having difficulty with the RS485. On the TCP/IP side, Port A (interface eth0) of the RevPi connects to the corporate lan and is configured for dhcp. Port B (interface eth1) is statically configured to IP address 192.168.0.101 and connects to a switch on a local device network. The static eth1 address is set in /etc/dhcpcd.conf. The PC has a dedicated network card with IP address 192.168.0.1 and connects to the device network switch. The PC runs DeltaV software which provides supervisory control of the RS485 devices; the gateway simply passes on the read/write commands received over Modbus TCP to the RS485 side. Every so often, DeltaV reports an Maintenance Ethernet IO alarm. The alarm corresponds to what we see in WireShark. A consistent pattern emerges each time: the device is queried, the query is acknowledged, but no data is sent. A timeout in DeltaV expires which triggers the alarm. DeltaV then sends a second query which is acknowledged by the RevPi followed by duplicate acks and the data. At this point, it looks like a problem in the RevPi network stack or possibly in the driver layer. Any help in how to trouble shoot this problem would be appreciated.

Regards,
John C.
Attachments
config.zip
config.rsc
(696 Bytes) Downloaded 2 times

Who is online

Users browsing this forum: No registered users and 1 guest