show the entry list
WinCC -- Operation and maintenance -- Diagnosing errors (evaluating diagnostics files)
How do you use the "SIMATIC Diagnostics Tool" (SDT) to collect diagnostics and system data?
How do you perform comprehensive diagnostics in PCS 7 and WinCC plants?
What do the error messages "Transfer buffer too small", "TagQueue overflow" and "Messages are lost" mean?
Why does the error "S7OPCIAX" occur in the event display?
How can you recognize resource bottlenecks in advance from WinCC and react to them accordingly?
Where can you find a description of the error messages of the Global Script diagnostics window in WinCC RT?
How can I determine the name of an action via the error message "Execute Error in Action @xxx"?
What can be the cause of the WinCC error message "More than 10000 actions in work" (up to V6.2: "More than 5000 actions in work")?
How can you back up the data of the Windows event viewer?
How do you save the diagnostics data of the Windows system monitor (performance monitor) in a file?
How can you define the amount of memory required for the performance indicator log of the Windows system monitor (performance monitor)?
Where can I find explanations of the error messages of the WinCC diagnostics files License.log, WinCC_SStart_xx.log and WinCC_Sys_xx.log ?
How do you evaluate and remedy "OnErrorExecute"-type configuration errors?
How do you write outputs from the "APDiag" diagnostic tool to a file?
How do you use the diagnostic tool "APDiag" to debug C scripts?
How do you determine the function name from the function ID in the case of APDiag-OnErrorExecute messages?
How do you start the "APDiag" script diagnostics tool?
How do you use the diagnostic tool "APDiag" to debug C scripts?
Part number:

Instructions:
In addition to the global script diagnostics window, the APDiag output window also supports the display of standard editions which are generated by means of "printf" instructions in C code

If you use your own C scripts, you should use appropriate "printf" instructions during creation in order to check that the script works properly. Once you have tested the entire C function successfully, comment out "printf" instructions that are no longer required. The following instructions are only intended as suggestions.
 
No. Note
1

Since the APDiag output window is the output window for all scripts, the outputs should be designed in such a way that the message text can be assigned quickly to the corresponding script. Therefore, the message text should contain the origin (e.g. name of the C function), as well as a unique error number.


Fig. 01   
 

In order to jump to the line which generates the "#I101" message in the C code, for example, open the "SIWATYP_PMP_StandardCycle()" project function. Then search for the line with the "printf" instruction containing the unique message number "#I101".

Note:
In the case of extensive scripts, the "Edit > Search" function can be used for searching.


Fig. 02  
 

2

In order to avoid having to write the function name out in every "printf" instruction, you can work with C preprocessor instructions. When the C function is compiled, the "TD_FUNCTION" string is replaced by "SIWATYP_PMP_StandardCycle".

The output line "HA_P_001_PMP_P_RM_DIAG_byState" is a bad example of a diagnostic message as it does not provide any unique indication of origin.


Fig. 03  
 

3

When a new C function is created, a "#I101"-type message can be installed as the first instruction in the program part. This allows you to ensure that the script call works correctly in runtime first of all.

4

"printf" instructions can be used as debug instructions. The successful call of a C function can be indicated by an information message (e.g. "#I202"). A call error would be indicated by an error message ("'E201"), however.


Fig. 04  
 

It is beneficial if the type of message can be determined straight away from the message number (error number). This would enable you to classify messages in errors (E for error), warnings (W for warning) or information (I for information).

5 As a general rule, your own C functions should also supply and "return" error information, facilitating debugging in the calling function. Fig. 04 shows that if a text field (in this case "szPVName") is read out incorrectly, the error code "-201" is returned to the calling function. Once a function has successfully ended, the value "0" or a value greater than "0" (warnings or information) can be returned.
6 Once the C function has been successfully tested, "printf" instructions which are no longer relevant (warnings or information which has become superfluous) are disabled. This can be done by simply "commenting out". This is done by inserting a double forward slash "//" at the start of the line.

Note:
It is often favorable if, following completion of the creation of a C function, only the error messages in the APDiag output window remain active. This also allows you to identify and remedy errors quickly at a later point in time. It is imperative to disable APDiag messages which are no longer relevant; otherwise, many messages which have become unimportant will have to be evaluated in the "APDiag output window later on. It often makes sense only to enable the information and warning messages which relates to the C function which is currently being processed.


 Entry ID:22196775   Date:2005-11-04 
I regard this article....as helpfulas not helpful                                 
mySupport
My Documentation Manager 
Newsletter 
CAx-Download-Manager 
Support Request
To this entry
Print
Create PDF 
Send to a friend
QuickLinks
Compatibility tool 
Help
Online Help
Guided Tour