The Industrial Raspberry Pi Forum

Attached is a png of the hardware setup. In the diagram, the RevPiConnect acts as a Modbus gateway passing on TCP/IP read/write requests to the RS485 slave devices. The slave device 64 occasionally responds to a valid Modbus RTU request with an exception response. We know this is incorrect and handle it in our code. That is why we run Proconx SW and not the Kunbus Modbus service. Again, the issue is the Kunbus failing to provide TCP/IP data after acknowledging receipt of the query from the PC. All Modbus RTU protocol errors with the slave devices (timeouts, etc.) are logged on the hard drive of the RevPi. When the RevPi fails to respond a query, the log file is clean and shows no errors. This means the problem is not with the RS485 devices failing to respond but rather the RevPi.

If you mean the "RevPi fault" is the response time (7 seconds between Pkt.4 and Pkt.10) of Trans 514, I would think the further time-measure between Address 64 and RevPi, and the latency of the software you used in RevPi is needed. Basically, I wouldn't think the ethernet port between RevPi and PC is the bottleneck.
If you mean the fault is the ACK missing of TCP segment (Pkt.6), I would think it is normal, which is the purpose of retransmission of TCP, however, it depends on the network environment. and it seems that the stack of 192.168.0.1 has dealt that well.
If neither matches your concerning, please give me a further clarifying.

The maximum latency between the RevPi and any of the RS485 slave devices is 600 msec. This value is the retry count * timeout which is 3*200 msec or 600 msec total. The retry count and timeout values are specified in the Modbus protocol. Normally, the round trip processing time is on the order of 20 msec which can be seen in the WireShark log for successful queries. If the RS485 device had in fact timed out in the read registers request, this would have been logged by the Modbus protocol as an error and the PC host notified of the error in the response message. However, the log file was clean with no errors. It appears that although the RevPi acknowledged the receipt of the initial query, the packet was lost as a result of an error in the TCP/IP stack or reading from the smsc95xx registers. If the message had been processed, the host would received a response prior to the retransmission which occurs 4 seconds after the initial query. The kernel logs did show a problem with interface eth1 (smsc95xx error) which is device network. At this point, I would like to create a debug build of the kernel with detailed instructions on how to do this and where to look in the code for errors.

Yes, you are right there is a bug of smsc95xx, which has been reported here: https://github.com/raspberrypi/linux/issues/183.
However, I didn't see any packet loss from the pcap file you provided, neither I don't think that issue is relavant to your scenario.
But if you really like to do the kernel debugging, you can do it. All needed information you can find in the tutorials: https://revolution.kunbus.com/tutorials ... es-jessie/

Regarding the bug (183), has this been fixed in Raspbian Stretch? This is the version we are running. The packet loss I'm referring to is the failure of the RevPi to respond in a timely manner to the initial query. Is there anything in the driver layer that could account for this?

Sorry, I currently have no information about the bug-fixing of 183.
As I said, I think probably the latency of the packet is caused by low-speed serial devices. Maybe you can do some measurement of that.
Ethernet is kind of high-speed devices, normally it works on 100Mbps, should be easy to deal with the throughput from the serial channel.

Hi,
I just saw you question on https://github.com/raspberrypi/linux/issues/183.
How is it going now? I hope you everything goes well.
Anyhow, I think it's not the same problem as issue 183, which maight cause packet loss.
As there is no packet drop in your case, but just late to arrive.