Error handling

The error handling of WinCC OA uses the following informations 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 as function names, User-ID, data point names and so on.

Such error informations are saved by the managers as variables of the data type errClass (respectively dyn_errClass) and normally output on the WinCC OA log file (se also the command line option "-log" or the entry of the config file logFile, logStdErr). Under Windows, the content of the PVSS_II.log from the console are automatically displayed in the Log viewer, and personal Log-files for the managers saved under <proj_path>/log. In Linux the Standard-Error is accessible via the pv2mon.

If the UI requests a non-existent data point attribute, for instance, only the UI or the CTRL program can know whether the non-existence of this attribute constitutes an error (the read request could also be a check to see whether this attribute actually exists). Therefore, in this case the UI must issue the error message, waiting for the response from the Event Manager before issuing an error message.

CTRL error message

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

An 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 where available:

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

This information means the following:

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

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

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
, s

For waiting control functions the configurator can read the last error to have occurred in this errClass using getLastError(). the configurator can output an error message for the user in dialog form using errorDialog() or output the error in the Standard-Error with throwError().

Note

Some functions (for example, dpSetWait(), dpCreate(), dpTypeChange(), ...) may return the value 0 although when the function fails (a failed function returns otherwise the value -1). This means that the user has to query the possible error via getLastError() and check if the function was executed successfully (see also the example of dpWaitForValue() below).

A failed function returns 0 for example,:

When a dpSetWait() is executed by a UI on a data point that does not exist. The UI knows that this data point does not exist and returns -1. If a dpSetWait() is executed on a nonexisting config/attribute of a data point element the function misleadingly returns 0 (the UI does not know whether the specific config exists or not). To check if errors occurred the user has to query them via getLastError().

The data type errClass respectively dyn_errClass can be used to store WinCC OA errors. An error variable can be assigned to another error variable or string variable. You can read the individual attributes using suitable functions.

Example

Example with dpWaitForValue():

main()
{

time t = 1;
dyn_errClass err;
dyn_string wait;
dyn_string ret;
dyn_anytype conditions;
dyn_anytype target;
conditions[1] = false;
wait = makeDynString("test.b:_original.._value");
ret = makeDynString("test_0.b:_original.._value");
dpWaitForValue(wait,conditions,ret,target,t);
err = getLastError(); // Test whether no errors
if(dynlen(err) > 0)
{
errorDialog(err); // Open dialog box with errors
throwError(err); // Write errors to stderr
}
else
{
DebugN("OK"); // No errors
}
}

Example

main()
{
rc=dpSetWait("Valve17.opening:_default.._type",DPCONFIG_DEFAULTVALUE);
DebugN(rc);
if ( dynlen(getLastError()) ) ... errorhandling ...
}

V 3.11 SP1