Debugging a protocol driver using serial communications

To debug a protocol driver that uses serial communications, do the following:

1. Keep using your Simple As Possible Project (SAPP).
2. Set the "DebugStr=* all" for your protocol.
3. Backup and delete both the syslog.dat and syslog.bak files. The system will recreate a fresh version of this file the next time CitectSCADA is started.
4. Start the project. From the information you can see in the maximized Main window of the kernel be able to see if CitectSCADA is sending requests to your I/O Device to initialize communications with it.

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:

• The request CitectSCADA is sending is not getting to the I/O Device - Check the Address field in the I/O Devices form, and verify that it is correct. If the I/O Device is one that needs a unique identifier (such as a node address), or you need some type of routing path, then verify that it is correct.

• 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.

• The Response from the I/O Device is not getting to CitectSCADA - This is unlikely and usually caused by cabling that is damaged, has insufficient bandwidth, or is connected improperly.. Check your cabling as above. Also, check that you are specifying everything you need within CitectSCADA. Many protocols require CitectSCADA to send a unique identifier in its request packet. If this identifier is incorrect then the response cannot get back to CitectSCADA.
• The I/O Device does not understand the Request - Every CitectSCADA protocol can check if an I/O Device is running. Typically the protocol attempts to read data from the I/O Device, usually a status register or other register that is there. However, many pseudo-standard protocols, such as Modbus, do not conform to the exact specification for that protocol. Many protocols supplied with CitectSCADA have some extra parameters to allow you to choose the specific initialization request from CitectSCADA. These can be found in either the Online Help or the Knowledge Base. Check with the manufacturer of your I/O Device to confirm that it will respond to the request that CitectSCADA sends. If you are unsure of the request being sent for initialization, use DebugStr=* to get the actual variable address that CitectSCADA is asking for in its initialization.

• 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.

• The I/O Device is not functioning properly - There is usually some sort of software from the I/O Device manufacturer that can be used to diagnose any problems with the I/O Device.

See Also