Lantronix XPort APS: Modbus Protocol User Guide - Page 30

I cannot get a slave response

Get Lantronix XPort PDF manuals and user guides View all Lantronix XPort manuals
Add to My Manuals
Save this manual to your list of manuals

Page 30 highlights

10: Troubleshooting and Technical Support b. Delay to issue and get the poll onto the Ethernet. c. Delay for the poll to cross Ethernet and arrive error-free at the IAP Device Server device (may include retries and contention). d. Delay for IAP Device Server to process and queue Modbus/RTU poll. e. Delay for the serial link to be free (remember other master/clients may be actively polling). f. Physical delay to shift poll bit-by-bit across the serial link. g. Delay in the device to recognize, process, and start reply. h. Physical delay to shift response bit-by-bit across the serial link. i. Delay for IAP Device Server to process and queue Modbus/TCP response. j. Delay for the response to cross Ethernet and arrive error-free at the master/client (may include retries and contention). k. Delay for master/client to recognize need for poll. Delays a and k are defined by your OPC or DDE driver. For example, a driver that runs only once each 55 msec (using the old DOS timer slice) can have a variable delay here of between 0 to 110 msec. Delays c and i are defined by the complexity and load of your TCP/IP network. For example, if you are going through radio or satellite links, these delays routinely amount to 1000 msec (1 sec) or more per poll and another 1000 msec for a response. 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. Modbus Protocol User Guide 30

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
10: Troubleshooting and Technical Support
Modbus Protocol User Guide
30
b.
Delay to issue and get the poll onto the Ethernet.
c.
Delay for the poll to cross Ethernet and arrive error-free at the IAP Device Server device
(may include retries and contention).
d.
Delay for IAP Device Server to process and queue Modbus/RTU poll.
e.
Delay for the serial link to be free (remember other master/clients may be actively
polling).
f.
Physical delay to shift poll bit-by-bit across the serial link.
g.
Delay in the device to recognize, process, and start reply.
h.
Physical delay to shift response bit-by-bit across the serial link.
i.
Delay for IAP Device Server to process and queue Modbus/TCP response.
j.
Delay for the response to cross Ethernet and arrive error-free at the master/client (may
include retries and contention).
k.
Delay for master/client to recognize need for poll.
Delays
a
and
k
are defined by your OPC or DDE driver. For example, a driver that runs
only once each 55 msec (using the old DOS timer slice) can have a variable delay here
of between 0 to 110 msec.
Delays
c
and
i
are defined by the complexity and load of your TCP/IP network. For
example, if you are going through radio or satellite links, these delays routinely amount to
1000 msec (1 sec) or more per poll and another 1000 msec for a response.
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.