Debugging a Protocol Driver using Serial Communications

Topology > I/O Devices > Troubleshooting Device Communications > Debugging a Protocol Driver Using Serial Communications

Debugging a Protocol Driver Using Serial Communications

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

Keep using your Simple As Possible Project (SAPP).
Set the "DebugStr=* all" for your protocol.
Backup and delete both the syslog.dat and syslog.bak files. The system will recreate a fresh version of this file the next time Citect SCADA is started.
Start the project. From the information you can see in the maximized Main window of the kernel be able to see if Citect SCADA 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 Citect SCADA. 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 Setup Wizard, and configure the computer for a standalone configuration.

If there are requests being sent but no reply, then Citect SCADA is trying to communicate. When Citect SCADA is sending requests but getting no reply, these are the most common causes:

The request Citect SCADA 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. Citect SCADA usually places a far higher constant load on serial communications than programming software does, this usually means that Citect SCADA 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 Citect SCADA. 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 Citect SCADA 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 Citect SCADA and show you exactly what is going through the COMx driver.

The Response from the I/O Device is not getting to Citect SCADA - 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 Citect SCADA. Many protocols require Citect SCADA to send a unique identifier in its request packet. If this identifier is incorrect then the response cannot get back to Citect SCADA.
The I/O Device does not understand the Request - Every Citect SCADA 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 Citect SCADA have some extra parameters to allow you to choose the specific initialization request from Citect SCADA. 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 Citect SCADA sends. If you are unsure of the request being sent for initialization, use DebugStr=* to get the actual variable address that Citect SCADA is asking for in its initialization.

Check the protocol you are using. Citect SCADA 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.