Applies To:
  • CitectSCADA 5.xx

You may see unit not responding communication errors with Citect ethernet drivers;

Wed Nov 29 11:08:39 2000 50:40:14.635 Error: Unit not responding

WRITE 0007 PORT5_BOARD1 Sub15 000010 2

Generic 000007 Driver 00000021 (0x00000015)

With Allen Bradley the errors may show up as a 0x2a driver error rather than a 0x15 driver error. What could be wrong?



Citect drivers for PLCs with ethernet communication modules, for example, MODNET, FINS, TITCPIP, ABTCP, etc may need tuning if the above symptoms are encountered. This is a step by step procedure and can be used to eliminate the intermittent communication errors;

The driver parameters in the Citect.ini files need to be tuned to the performance of the PLC network.

1. In the Citect Kernel window, view | drivers you will see performance figures for min, max and average response times.

 Increase the Driver parameter TimeOut= to match the worst response time. This is usually around 3000 mSec. in a live system.

2. Step 1 should improve matters but on some systems the problem may persist. This means Citect is requesting information too quickly.

Decrease the driver parameter MaxPending=1.

(For the MODNET driver this can be better achieved using MaxOutstanding=1)

3. If there are still intermittent communication breaks then Increase the Driver parameter

Delay=20 or up to 50 mSec.


TITCPIP will show up as other errors and these can be overcome as shown in KB Article Q2856.

The above communication errors are not necessarily Citect caused, unit not responding indicates that the PLC has gone silent, possibly due to overload with communications requests.

Driver parameters show up in run time in the Citect Kernel window, view drivers. You can adjust the above parameters using the Citect Help Topics | Find | type in the protocol name, then in the topics you will see "protocol parameters".