The alarm corresponds to what we see in WireShark. Every so often, DeltaV reports an Maintenance Ethernet IO alarm. 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. The PC has a dedicated network card with IP address 192.168.0.1 and connects to the device network switch. The static eth1 address is set in /etc/nf. Port B (interface eth1) is statically configured to IP address 192.168.0.101 and connects to a switch on a local device network. On the TCP/IP side, Port A (interface eth0) of the RevPi connects to the corporate lan and is configured for dhcp. Overall, we are not having difficulty with the RS485. The RS485 baudrate is 38400 bit/sec, 8 bits, 1 stop bit, no parity. It's job is to communicate via another RS422 network with a set of brushed motors. The value 1 is an RS485 Wago and 64 is a custom realtime board called the "comm board". The RS485 side has two slave devices with Modbus ID's of 1 and 64 respectively. The RevPi is used as a TCP to RS485 gateway. cat /etc/revpi/image-release gives -revpi-stretch. There is no os-release, just image-release. WireShark.png (176.73 KiB) Viewed 7284 times The log file is clean and shows no errors.Ĭan anyone provide any explanation for this behavior? Also, the Modbus protocol we are running logs all protocol failures including slave device timeouts to a log file. The packet data of the initial query triggering the retransmission has been verified to be a valid Modbus request. Normally, the initial query from the host is immediately (within 50 msec or less) followed by a response from the Pi with valid data. This behavior is exhibited somewhat randomly once every 24 to 36 hours and is causing a problem for our host PC control software. After that, the RevPi responds with an acknowledgement followed by a duplicate acknowledgement, then the response data. The PC then issues a second query which initiates a TCP Retransmission. Beginning at line item 4, the PC host issues a query to the Pi which responds with an acknowledgement however, more than 4 seconds elapse (4.364) without a response which exceeds a timeout in the host PC software. No other devices exist on the network other than network switches. This network is local to the PC and RevPi. The host PC has static address of 192.168.0.1. The eth1 interface of the RevPiConnect is configured to have a static IP address of 192.168.0.101. All slave devices have been independently verified to consistently respond to read/write requests within 20 msec or less without failure.Īttached is a snapshot of data from WireShark running on the PC host. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |