To debug a protocol driver that uses serial communications, do the following:
syslog.bakfiles. The system will recreate a fresh version of this file the next time CitectSCADA is started.
If there are no requests being sent then your software is improperly configured, and check that there were no errors on Startup of CitectSCADA. If there were errors on startup look them up in the Online Help. Also check that your computer is an I/O Server (and that it matches the one in your project). To do this run the Computer Setup Wizard, and configure the computer for a standalone configuration.
If there are requests being sent but no reply, then CitectSCADA is trying to communicate. When CitectSCADA is sending requests but getting no reply, these are the most common causes:
Check that you have the same parameters in the Ports form that the I/O Device is using. If you have 8 data bits and the I/O Device uses 7 data bits, communications will not work.
Check that your cable is OK. The easiest way to do this is to create a new project and use the Loopback protocol. You can use this to verify the Tx and Rx lines' integrity by placing a jumper on these lines. Initially test this with a jumper between pins 2 and 3 on your PC. Then plug in your cable and test again with the jumper between the Tx and Rx lines. Keep moving the jumper until it is at the end of your communications bus. You can find more information on using the Loopback protocol in the Citect Knowledge Base.
Even if the Loopback protocol shows no errors, your cable might still be responsible for the loss of communications. CitectSCADA usually places a far higher constant load on serial communications than programming software does, this usually means that CitectSCADA will require much more stringent handshaking than the programming software. So it is possible that the cable you use to program your I/O Device works fine for programming, but not for CitectSCADA. Check the Wiring Diagram for your Protocol in the help.
Another major cause of improper cable connections is 9-pin to 25-pin converters. Many of these converters are made specifically for serial mice. These typically only use the Tx, Rx and Ground signals. If you use one of these converters they do not support any handshaking and will most likely not work for your Protocol.
If the above checks OK, use the parameters for COMx (as mentioned above) to create log files. Examine these log files and verify that what CitectSCADA thinks it is sending is actually what it is sending. The log files produced by using these parameters get their information from a lower level than CitectSCADA and show you exactly what is going through the COMx driver.
Check the protocol you are using. CitectSCADA may have many different protocols for communicating to an I/O Device. PLCs such as the AB PLC5 can use different serial protocols, depending on the method you are trying to use. Make sure you are using the correct one. If you are unsure, try the other possible protocols.