RuggedCom Welder RS400 用户手册
Serial Protocols
RS400
91
ROS™ v3.5
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?
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.
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.
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.
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?
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.
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?
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.
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.
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.
packet sizes, message directions and timeout events occurrences.