Applies To:
  • CitectSCADA 5.xx, 6.xx
  • CitectHMI 5.xx, 6.xx
Summary:
I have setup Citect to communicate to an RTU via the Modbus protocol over an RS232 link. The Main RTU has many out stations connected via a radio link, so there are several I/O devices configured in Citect.

Randomly the communications would stop working correctly, and the driver would return with a garbled or response bad error.

Through further investigation using Portmon and a driver trace, it was found that Citect makes a request for the data twice. At which point, all communication seems to get mixed up.

A port monitor trace illustrates the problem:

335746 4:00:56 PM Citect32.exe IRP_MJ_WRITE Serial0 Length 8: 02 01 01 30
00 10 3C 06

335749 4:00:57 PM Citect32.exe IRP_MJ_WRITE Serial0 Length 8: 02 01 01 30
00 10 3C 06

Is this a bug in the Modbus driver? How do I resolve this problem?
 

Solution:
This is not a bug in the Modbus driver. This problem would never occur on a true point to point link. It really occurs because of the multidrop architecture running over the serial link. The driver is behaving as expected.

At the time of publishing this KB, the default Modbus parameters are:
MaxPending=2
Block=50
Retry=1
Delay=0
Timeout=1000
Watchtime=30000

From the Portmon trace you can clearly see that a second request is sent out EXACTLY 1 second after the first request. And it is for the exact same I/O device (slave 2), and request type 1.
This second request is simply a retry, since it has not received a response within the timeout period. The Modbus driver will only ever have one request outstanding on the wire at any given time. The reason why this was causing the garbled data, is that the rtu received the second request (retry) and was still processing it. Meanwhile the unit finally timed out, and a different request for data was sent out. The RTU finally returned with the original request, which now conflicts with the response Citect was expecting. This then causes the driver to flag the data as bad, and raise the hardware alarm.

To resolve this problem, the following Citect.ini parameters were set:
[Modbus]
Retry=0 (this is going to have a direct effect on solving the request mix up)
Timeout=2000 (This is will give the RTU more time to respond to requests)

Since the I/O devices are connected to the RTU over a radio link, a 1000 msec timeout was inadequate. Please keep this in mind when communicating over slow serial or radio links.
 
Keywords:
Modbus, garbled, retry, RTU 

Attachments