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.
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.
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".
In the case of extensive scripts, the "Edit > Search" function can be used for searching.
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.
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.
"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.
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).
||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.|
||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.
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.