RuggedCom RS400 manual Problem Two, Problem Three, Problem Four

Serial Protocols

2.4 Troubleshooting

Problem One

I configured a Serial IP to use TCP transport ( in or out connection request direction) but nothing seems to be happening. What is going on?

Ensure that an Ethernet port link is up.

The peer may not be requesting (accepting) connections. The Connection Statistics Table will display whether the connection is active or not.

The peer may not be sending data. The Connection statistics Table will display the counts of transmitted and received data packets via IP network.

Watch the connection activity. For a detailed description of the TCP connection activity, turn on tracing at the TRANSPORT level.

Problem Two

My connections (as shown in the Connection Statistics Table) go up and then immediately go down again. What is going on?

If two ports (on the same or different RuggedServers™) are configured to call the same IP/TCP port in the network, only the first one to call will be successful. All other ports will fail, displaying the attempts as brief periods of connection in the Connection Statistics Table.

Problem Three

My Modbus polling is not working. I am sure that a connection is occurring but my Master reports an error connecting to the device. What is happening?

Are framing, parity or overrun errors reported at either the client or server?

Is the Server Gateway set up for the correct baud, parity and stop bits? Is the RTU online?

Is an adequate response timer configured at the server? Is the Master’s time-out long enough? Is the Master pausing in the middle of transmitting the request? Some versions of the Windows OS have been observed to display this behavior as load is increased.

Could the IP network be splitting the Modbus message into two TCP segments?

Ultimately, it may be necessary to view the contents of messages transmitted over TCP (by activating tracing at the IP level) or by viewing messages at the serial port level (See the section on tracing at the SERIAL level.) Start by tracing at the client, ensuring that it is receiving and forwarding the request over IP. Then, if needs be, trace at the server to ensure that it is receiving the request and forwarding to the RTU. Verify that the RTU is responding properly.

Problem Four

How do I get figures (like those presented earlier in the chapter) for my own analysis?

Activating tracing at the IP level and serial port level. The trace package displays timestamps, packet sizes, message directions and timeout events occurrences.

RS400 91 ROS™ v3.5