Troubleshooting 72 If there is a terminal server between the CIU and the interface machine,
disable the XON/XOFF flow control in the terminal server port. Disabling the XON/XOFF is necessary because the CIU protocol is binary and the data may contain binary code 19 (which is the ASCII code for XOFF), locking up the terminal server port. Also set the port data rate to match the CIU module data rate and the data rate specified in the command file The interface sometimes functions properly during the point establishment phase but fails to read exceptions. This type of problem normally occurs in a heavily loaded terminal server. Since the read exception call can return up to 1600 bytes of data, the CIU can overrun the terminal server buffer, causing a read error for the interface. You may need to increase the type ahead of the buffer or use hardware flow control on the interface port on the terminal server. The best solution fora particular system depends on the type of terminal server used.
Bailey Loop Problems For early versions of the CIU04, when the interface tries to disestablish the CIU index of a station block, the CIU module will be hung up (stay in error state with red light in front of the module. The interface then cannot communicate to the CIU module and reports timeout error messages to the log file. The PI points will stop getting new snapshot values. This problem would only occur if more than one PI point are configured to read attributes from a station point, that is, one reading
PV and one reading the mode, and one of these PI points is modified. This is a CIU problem that only occurs for CIU04 with firmware version earlier than E. Thus, if the CIU04 module firmware version is earlier than E, contact ABB / Bailey to obtain an upgrade. Another commonly reported problem is that PI points have a Bad Input status and are not getting updated, that is, the snapshot timestamp does not change. This problem maybe caused by one of the following scenarios If the PI point is newly created and the interface has no problem establishing
the point on the CIU module, then most likely the point has the wrong Bailey address. The CIU module does not verify that there is an actual exception source of the same point type during point establishment, and therefore, the point could be established on the CIU but will receive no exception report in the future. Ensure that each PI point has the correct Bailey address. If the PI point has been collecting data but suddenly gets Bad
Input and then no more events, the problem is most likely caused by an upset in the Bailey loop communication. For older versions of the Bailey loop communication module, the module does not reestablish the exception report routes after an upset, especially for routes across a network bridge. The CIU module has to reestablish the point in order for the PCU to resume sending exception report. You can force the CIU tore- establish the point either by restarting the interface or by changing one
of the nonessential attributes, that is, typical value, on the problematic PI point.