Owners manual

6: Troubleshooting and Technical Support
Modbus Protocol User Guide 25
Delays f and h are defined by the baud rate. Assuming an 8 bytes poll and 255-
byte response, at 9600 baud this is at least 275 msec, while at 1200 baud, this is
at least 2200 msec (2.2 sec).
Delay g is defined by the device. Oddly enough, the simpler the device, the faster
it tends to reply. Some controllers only allocate fixed time slices to process a
response from shared memory – for example once each 100 msec.
Delays d, e, and i are defined by the load on the IAP Device Server. If other
master/client are polling, the queuing delay for e can be large (the sum of delays
f, g, and h) for each earlier poll waiting.
I cannot get a slave response
Besides the obvious wrong baud rate, there are many possible causes of this:
 Is your cable set up correctly for RS232 or RS485? On the XPress DR-IAP,
is the external red switch set correctly?
 For RS485, you need to short the TX+ to the RX+ and TX- to the RX-
externally.
 The XPress DR-IAP has a floating ground that is fully isolated from the power
supply. An external Signal Ground connection is often required between the
IAP and your device.
 The IAP Device Server firmware only expects Modbus/TCP from the
network. Some applications just pack Modbus/RTU raw in TCP – this is not
supported.
 Your slave is set for 2 stop bits and your UDS-10-IAP does not support
2 stop bits.
Only Slave ID #1 can be polled
Your application is setting the Modbus/TCP Unit ID field to 0. This causes the IAP
Device Server firmware to automatically map this to 1.
Every 2
nd
poll seems to fail
Most likely you are using RS485, but regardless, your device probably cannot accept
a new poll as fast as the IAP Device Server firmware is sending it. TCP/IP is a full-
duplex channel, and since you can have up to 8 active sockets, it is very easy to
have a new request already waiting as your last response is being returned. The only
solution to this is to slow down your Modbus/TCP masters so they never poll before
the last response has been seen. This manually creates the time delay between polls
your device expects.
 My IAP Device Server runs fine - for about 10 minutes and then my
applications start reporting slaves going off-line.
 My IAP Device Server runs fine – until a slave goes off-line; then I tend to
lose all the slaves or they all poll only intermittently.
 Sometimes my IAP Device Server returns the wrong data from the wrong
slave.