Differences

This shows you the differences between two versions of the page.

--- debugging_complex_programs [2018/12/26 10:53] – [First scan] emozolyak
+++ debugging_complex_programs [2018/12/26 11:12] – [Running backup on the new device] emozolyak
@@ Line 37: / Line 37: @@
 If the order of execution of the scripts is 1 - 2, then everything will work, because at the current scan start script #2 saw one value, and before its execution another one(which script #1 has changed before), and will correctly work 'by changing the state of the register.' If the script execution order is interchanged, then script 2 will not work, because at the the current scan start it will see the changed value, and the new change will occur after script #2 execution in script #1.
+===== Running backup on the new device =====
+If you take the new WebHMI with clean internal DS - memory, where some complex project has to be run, usually you need some presets (initial values) for correct operation. You can use a recipe feature and make a list of all registers with initial values, and then just apply this recipe.
+If the project was linked to Level2 account, when restoring its backup on the new WebHMI, check that Level2 integration is switched off, otherwise this WebHMI may interefer another one which use same Level2 account.
+===== Debug messages =====
+It is desirable after the key moments of logic or calculations in scripts to immediately put the functions INFO, ERROR, DEBUG, TRACE, with respectve values at this point, script's name, line number at the beginning. Then these fragments are conveniently searched and analyzed in the communication log.
+When there is a lot of records in the communication log, you can filter out unneccerary output from scripts with this [[http://docs.webhmi.com.ua/useful_programs#debug_printing|method]]
+In the script editor, there is a debugging console, which always prints out the functions INFO, DEBUG, ERROR, TRACE regardless of the system log level settings.
+However, in a large system with many interrelated scripts, when there is a lot of debugging data, it becomes inconvenient to look for the necessary data, especially if you need to track a specific chain of execution of several scripts that can not be called at specific moments, not in each scan.
+In addition, filtering unnecessary information in logs is also useful from the point of view of performance, since operations of permanent recording on a flash card of a large amount of information can reduce system performance.
+You can proceed as follows - assign your debugging function, which will be called only if the debug printing of this script is allowed. For example, you can write the ids of the scripts in the 'debug_ID' string in which debug printing is needed at the moment, and the print function inside the script will look at this number and turn it on or off. For example: