Owners manual

2: Configuring Modbus
Modbus Protocol User Guide 14
Modbus broadcast from a serial master device is discarded regardless of this
parameter setting.
Use MB/TCP 0x0B/0x0A Exception Responses (1=No 2=Yes)
Traditional serial Modbus uses silence to signal some errors. While this works well
with direct serial lines, it causes serious problems on a TCP/IP wide-area-network
where delays are not so predictable. See for a full discussion.
Setting this parameter to 1/No causes the IAP Device Server to behave like a
traditional Modbus serial slave – it answers timeouts, unconfigured slave addresses,
and CRC errors with silence.
Setting this to 2/Yes causes the IAP Device Server to return 1 of 2 new exception
codes defined in Modbus/TCP.
Consider exception hex 0A (PATH UNAVAILABLE) a “hard” error where a retry is not
likely to succeed. It is returned:
 If slave-attached – currently never. However, future firmware may allow the
user to define the range of valid slave addresses.
 If master-attached – if a Modbus request has a slave address that is not
configured in the Unit ID to IP mapping table.
 If master-attached – if the TCP socket failed to open. This is really a soft-
hard error, as the reason the TCP socket failed to open may be transient or a
hard configuration error.
Consider exception hex 0B (TARGET DEVICE FAILED TO RESPOND) a “soft” error
where a retry may succeed. It is returned:
 If slave-attached – if the slave didn’t answer or the answer contained a CRC
error
 If master-attached – if a TCP socket is open, but no response was received
in the defined message timeout.
 If master-attached – if a TCP socket is open, but the remote Modbus/TCP
slave/server returned exception 0x0B.
Disable Modbus/TCP pipeline (1=No 2=Yes)
While the Modbus/TCP standard specification requires Modbus/TCP masters/clients
to only issue one poll at a time, the full-duplex flow-controlled nature of TCP/IP allows
them to issue more than one at a time, and the TCP socket will buffer them. The IAP
Device Server will fetch them one at a time and answer each in turn. See
6:Troubleshooting and Technical Support for a full discussion of the problem this can
cause.
Setting this to 1/No causes the IAP Device Server to allow this queuing or pipeline
behavior. This is the safest default setting – only change this to disable if you are
having problems.
Setting this to 2/Yes causes the IAP Device Server to always fetch the newest
request from the TCP buffer – all older requests are discarded. This allows a
Modbus/TCP master/client to retry old requests without risking building up a stale
queue of waiting requests.