Applies To:
  • CitectSCADA
Summary:
Large ControlLogix applications using ABCLX driver. Standby Ioserver causes primary Ioserver to disconnect and vise versa (connections toggle).
This is essentially caused by the PLC being overloaded (too many tags / logic etc). In particular, the subscription phase of a connection places a high load on the PLC and this impacts the performance of all other operations including any existing connections.

The group poll times on the existing connection blow out dramatically when the second IOServer is subscribing its opt blocks. With default settings the original connection times out and goes offline. The second connection then gets through. The two connections then flip flop, alternately knocking each other out.

Solution:
The group poll timeout this driver uses is:

   MAX(Timeout, ScanRate * MissedPollTolerance)

The parameter MissedPollTolerance is not actually limited to the range 1-5, the
documentation is really just reflecting recommended value ranges.

So the suggested settings to start with for a highly loaded PLC that is displaying the above symptoms, are

[ABCLX]
timeout = 5000
scanrate = 2000
MissedPollTolerance = 100

If that is successful work back from there. With the adjusted settings applied, both IOServers should get online eventually. Even though the group poll times on the existing connection get large (slowing data updates and potentially affecting other PLC operations) while the second connection is subscribing, once they both are online the group poll times on both IOServers will balance out to more reasonable times (depending on the timeslice setting in the PLC).

Notes:
  • All tags are subscribed, so any in the variable.dbf that are not used should be removed.
  • The general ABCLX tuning advise in Q4035. This should be followed before this KB. The scan time should be set even more conservatively (relative to the average group poll time) when there are two IOservers connecting to the same PLC.
  • Even if you manage to work around the issue with the above technique, your PLC is overloaded and you really need to reconsider your system architecture and try to distribute the PLC project amongst several CPU's. The parameters will not be able to be increased infinately.
  • The overload may not be obvious in terms of scan time. The problem has been observed when there is no logic in the PLC at all, but only a very large tag list of which Citect does not have to be subscribing to all. eg 100000 tags in PLC, Citect subscribing 30000
Keywords:
 ABCLX, ControlLogix, load, performance

Attachments