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 Plant 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 Plant 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 Plant 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 Plant SCADA is trying to communicate. When Plant SCADA is sending requests but getting no reply, these are the most common causes:

• The request Plant 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 about the Loopback protocol via the AVEVA Knowledge and Support Center. Search for "Loopback".

  Even if the Loopback protocol shows no errors, your cable might still be responsible for the loss of communications. Plant SCADA usually places a far higher constant load on serial communications than programming software does, this usually means that Plant 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 Plant SCADA.

  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 Plant 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 Plant SCADA and show you exactly what is going through the COMx driver.

• The Response from the I/O device is not getting to Plant 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 Plant SCADA. Many protocols require Plant SCADA to send a unique identifier in its request packet. If this identifier is incorrect then the response cannot get back to Plant SCADA.

• The I/O device does not understand the Request - Every Plant 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 Plant SCADA have some extra parameters to allow you to choose the specific initialization request from Plant SCADA. These can be found in either the Online Help or the AVEVA™ Knowledge & Support Center. Check with the manufacturer of your I/O device to confirm that it will respond to the request that Plant SCADA sends. If you are unsure of the request being sent for initialization, use DebugStr=* to get the actual variable address that Plant SCADA is asking for in its initialization.

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

See Also

Debugging Proprietary Board Drivers