Error handling

Overview

The error handling of WinCC OA uses the following information to manage the errors:

  • Number of the error
  • Date and time of occurring
  • Priority (Fatal, Severe, Warning, Info)
  • Classification (System/Implementation error, configuration error, WinCC OA system error...)
  • Additional information such as function names, User-ID, datapoint names etc.

Error Information Output

Error information is saved by the managers as variables of the data type errClass (respectively dyn_errClass) and normally output on the WinCC OA log file. See also the command line option "-log" in the chapter General options and the config entries logFile, logStdErr.

On Windows, the content of the PVSS_II.log from the console is automatically displayed in the Log viewer and personal Log-files for the managers are saved under <proj_path>/log.

errClass Variables

errClass variables are generated by managers, for example when starting a manager or when a UI requests a datapoint attribute from the Event manager and the attribute does not exist. In this case, only the UI or CTRL knows whether the non-existence of the data point attribute is an error. Therefore, in this case the UI must issue the error message.

The UI waits for the response from the Event manager dpRename(), dpCreate(), dpTypeChange() etc. The answer contains a dyn_errClass variable. The variable can be queried viagetLastError() and can then be processed via errorDialog(), throwError() etc.

CTRL Error Message

If a CTRL script finds an internal error, which the programmer does not handle when running the program (for example, the programmer forgot to declare a variable before using it), then CTRL creates an errClass variable for the WinCC OA error handling. Usually the system writes the contents of the errClass variable in the WinCC OA log file.

A CTRL error message contains, amongst other information, the file and line number in which the error occurred. The error message format contains the following information:

Panel: Filename[Panelname]
                Object: Serialnumber [Objectname]
                In Panel-Reference: Filename [Referencename]
                Filename [Referencename]
                Filename [Referencename]
                ...
                Filename [Referencename]
                File: Filename:
                Script: Name of the property concerned
                Line: linenumber

Error Message Information

Information Meaning
Panel The panel in which the error occurred
Object The object in which the error occurred
In Panel-Reference If the graphics object is a reference, then the whole hierarchy is given here. At the top is the panel in which the graphics object is defined, then all parents of the panel successively.
File The file in which the error occurred, for example, a CTRL library.
Script Property name for which the erroneous CTRL script was written.
Line Line number

CTRL Error Message Example 1

WCCOANG(1), 2003.06.30 12:51:30.857, CTRL, WARNING, 78, Assignment to this expression impossible,
                Panel: test_ctrl_fkt.pnl []
                Object: 0 [Button1]
                Script: EventClick
                Line: 3

CTRL Error Message Example 2

WCCOANG(1), 2003.06.03 12:51:30.857, CTRL, WARNING, 73, Variable not defined,
                Panel: test_ctrl_fkt.pnl []
                Object: 0 [Button1]
                Script: EventClick
                Line: 3

Handling Errors with CTRL Functions

For waiting control functions you can query the last error occurred in this errClass by using getLastError(). You can output an error message in dialog form using the errorDialog() or output the error in the Standard-Error via throwError().

Handling CTRL Errors as Exceptions

Alternatively, CTRL errors can be handled as exceptions. The function setThrowErrorAsException() enables the current thread to throw an exception in case of an error. The exception can then be caught and handled using a try/catch block. The last exception can be queried using getLastException().

Handling CTRL Errors as Exceptions Example

​setThrowErrorAsException();
time t;
try
{
  t = (time)"2022-99-99T01:03:00.567";
}catch
{
  dyn_errClass err = getLastException();
  DebugN(err);
}}

The example outputs:

WCCOActrl2:[dyn_errClass 1 items WCCOActrl2:WCCOActrl (2), 2023.03.03 13:40:00.166, CTRL, WARNING, 51, 
                Parameter incorrect, TimeVar, operator=, format >error. Must be: YYYY-MM-DDTHH:MM:SS.mmm WCCOActrl2: 
                Stacktrace: WCCOActrl2: 1: void main() at tests\TestFile.ctl:61 WCCOActrl2:]

Checking Errors with getLastError()

Some functions (for example, dpRename(), dpCreate(), dpTypeChange(), ...) may return the value 0 although the function fails. You have to query the possible error via getLastError() and check if the function was executed successfully meaning the getLastError does not return an error (Function OK). The following example for dpRename() shows the dpRename function and an error that is queried via getLastError(). Note that you call getLastError() directly after the function call.

Checking Errors with getLastError() Example

main()
{
  dyn_errClass err;
  dpRename("ExampleDP_Arg1.", "ExampleDP_Arg1.");
  //Returns 0, sets the getLastError()
  err= getLastError();
  DebugN("Error is:", err);
}

The example outputs:

WCCILdata (0), 2018.02.21 14:33:08.128, PARAM,SEVERE, 36, DM: Incorrect name syntax, PersDpIdentification, 
                handleManipNameMsg, New DP name wrong WCCOAui1:["Error is:"][dyn_errClass 1 items 
                WCCOAui1:WCCOAui (1), 2018.02.21 14:33:08.128, PARAM,SEVERE, 36, DM: Incorrect name syntax,
                PersDpIdentification, handleManipNameMsg, New DP name wrong WCCOAui1:]