Problem Reporting - Getting the Right Information

[Anonymous user]

📖 Home  Back  
While significant effort is spent in development and testing to ensure that any issues with ClearSCADA are resolved prior to each version being release, from time to time you may have cause to contact Technical Support to help resolve a problem with your system.

The aim of this page is to provide information on what type of information is required to help us diagnose what is happening with your system in the shortest possible time.

We can define a number of broad types of issue and then the information that we would require to help diagnise that type of problem. Those issue types include:

• Server stability, crashes, exceptions

• Redundancy Problems

• Driver / Communications Problems

• ViewX Connection Problems

• ViewX Performance Issues

With any log files provided, please ensure that they cover the time of the reported incident. Log files from another time are generally not useful in diagnosing the problem.

Please refer to sections below to determine what information you should include with any report to Technical Support.

Server Stability, Crashes, Exceptions

This type of problem is generally, but not always caused by something going wrong in the server and it is the server information that you should provide. The following information is the basics:

• Server layouts eg. Redundancy, how many levels of redundancy etc

• The type of connection between servers e.g. Wireless, piece of wet string, fibre, Ethernet etc

• RTU / PLC architectures and protocols e.g. Large radio network connected through terminal server talking DNP3.

• The exact time that the problem occurred (so we can find it in logs) and anything you are aware of leading up to the problem.

• The following log files:

• Server Snapshot Logs from the server exhibiting the problem

• DBServer Logs - please verify that these cover the appropriate time period where the problem is evident including any time leading up to the problem beginning.

• Relevant Exception Minidump files (if the problem is an exception). Look for the file with the mdmp extension in the Dumps directory.

From ClearSCADA 2007 R1, when an exception occurs, other logs will be packaged up with the minidump in a single zip file. Please send the zipped file rather than individual log files, but still ensure that the right information is provided on top of the zip as described on this page.

Redundancy Problems

To diagnose issues with the redundancy process, the following information will be needed:

• Server layouts eg. Redundancy, how many levels of redundancy etc

• The type of connection between servers e.g. Wireless, piece of wet string, fibre, Ethernet etc

• The exact time that the problem occurred (so we can find it in logs) and anything you are aware of leading up to the problem.

• A screen shot or export of the event list showing times of key stages of synchronisation.

• The following log files:

• Server Snapshot Logs from the main server that covers the time synchronization started.

• DBServer Logs - please verify that these cover the entire time of the synchronization process.

Driver Issues

Driver issues typically require driver diagnostic information rather than other type of logs. However since the drivers communicate with the server, server logs are also useful. See the list below for information required to diagnose driver problems:

• RTU / PLC architectures and protocols e.g. Large radio network connected through terminal server talking DNP3.

• The exact time that the problem occurred (so we can find it in logs) and anything you are aware of leading up to the problem.

• The following log files:

• Driver log files. This is the log file that records the internal workings of the driver itself.

• IO logs from the channel to which the outstation is connected. This will show the transfer of data between ClearSCADA and the outstation / PLC.

• DBServer Logs - are not always needed, but can be useful an shoudl be supplied.

• Server Snapshot Logs are not generally required fro driver issues, but if available, send it in.

• Relevant Exception Minidump files for the driver (if the problem is an exception).

Client Connection Issues

For this type of issue, please enable Link Read-Write (DBLRW) logging from the Logging page in the server status dialog. This will provide information about the requests coming in on the links to the server. Ensure that this logging class is enabled prior to reproducing the problem, and once logs are retrieved, this class of logging can be disabled.

If the problem is related to the client not connecting to the server properly (eg. Connection not licensed, Crash on startup of ViewX, No Connection at all to server etc), the following are important:

• DBServer Logs from the server

• DBClient Logs from the client that cannot connect

• ViewX Logs from the client that cannot connect

• Export of the registry key named Systems from the HKEY_LOCAL_MACHINE\SOFTWARE\Serck Controls\SCX6\ on the ViewX client. This contains all relevant information relating to how the client connects to the server.

Performance Problems in ViewX

For this type of issue, please enable Link Read-Write (DBLRW) logging from the Logging page in the server status dialog. This will provide information about the requests coming in on the links to the server. Ensure that this logging class is enabled prior to reproducing the problem, and once logs are retrieved, this class of logging can be disabled.

Some problems to do with performance such as perceived slowness of screen load, or data updates will require log files from both client and server. See below:

• ViewX Logs from the client exhibiting the problem

• DBClient Logs from the same client

• DBServer Logs from the server to which the client is connecting

• Server Snapshot Logs for all servers the client is connected to (ensuring it is covered in the time period for the problem).

• Description of what action was undertaken and exactly what time to look for in the log file.

• If ViewX isn't responding, also supply information about handle count, user objects and GDI objects used by ViewX, whilst it is in the non-responsive state. See How to Find ViewX Resource Usage)

These types of problems can only be diagnosed when you can see both ends of the chain and this is where it is important to send both ViewX side and DBServer log files.

Can the Problem be Repeated?

If possible, try and repeat the problem on a test system. If a sequence of events can be supplied that help to reproduce the problem, then it will be much simpler to resolve. If you can reproduce it, please provide the information requested for each type of issue above. Also the following would be useful:

• An export of the database, or relevant section of configuration to help reproduce the problem.

• A detailed sequence of steps describing how to recreate the problem.

Other problems

If you are not sure what logging is required, call your local Tech Support team and ask what information they require. This will help them in resolving your problem, and also allow you to only have to send in informaiton once (as much as possible).

Go: Home Back