debugging_complex_programs
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
debugging_complex_programs [2018/12/26 10:53] – [First scan] emozolyak | debugging_complex_programs [2021/08/04 15:20] – [Proper commenting] emozolyak | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | |||
+ | |||
====== Debugging complex scripts ====== | ====== Debugging complex scripts ====== | ||
===== Project initialization ===== | ===== Project initialization ===== | ||
+ | |||
+ | |||
==== Non - volatile registers ==== | ==== Non - volatile registers ==== | ||
Line 29: | Line 33: | ||
Remember that registers such as Dxx, CDxx and other internal registers, except for DSxx, return to the initial state (usually 0) after initializing the project (which happens when editing project elements - scripts, registers, connections, | Remember that registers such as Dxx, CDxx and other internal registers, except for DSxx, return to the initial state (usually 0) after initializing the project (which happens when editing project elements - scripts, registers, connections, | ||
- | ===== Differences between write function for internal | + | ===== Differences between write function for internal/external |
There are some differences in the operation of the SetReg and WriteReg functions with respect to internal registers (Dxx, DSxx). These functions directly change the values of the internal registers inside the scan, and do not delay WriteReg writing to the next scan start. Thus, at the end of the scan, the internal register can have a value different from the one at the scan input. Then, for example, a situation is possible where: | There are some differences in the operation of the SetReg and WriteReg functions with respect to internal registers (Dxx, DSxx). These functions directly change the values of the internal registers inside the scan, and do not delay WriteReg writing to the next scan start. Thus, at the end of the scan, the internal register can have a value different from the one at the scan input. Then, for example, a situation is possible where: | ||
Line 37: | Line 41: | ||
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 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.' | ||
+ | |||
+ | ===== 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' | ||
+ | |||
+ | When there is a lot of records in the communication log, you can filter out unneccerary output from scripts with this [[http:// | ||
+ | |||
+ | 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. If the output changes too quickly to analize, you can slow down the script by changging in execution type to " | ||
+ | |||
+ | There are also messaging functions like [[ http:// | ||
+ | |||
+ | ===== Modular principle ===== | ||
+ | |||
+ | It is recommended that you split complex scripts into simpler and more frequently used functions that you can reuse. Dividing tme into simpler parts, arranging them in the right order and grouping helps to control the logic of the system and makes it easier to set up the system. | ||
+ | |||
+ | ===== Proper commenting ===== | ||
+ | Use commenting you will understand next time you or someone will see you code. | ||
+ | <code lua> | ||
+ | ----------------------------------------CALC. DAY ECONOMY -------------------------------------------------- | ||
+ | LimitMonthDayYesterday = GetReg(" | ||
+ | HeatEnergyDay = GetReg(" | ||
+ | WriteReg(" | ||
+ | ------------------------------------------------------------------------------------------------------------ | ||
+ | </ | ||
+ | |||
+ | ===== Step over trick ===== | ||
+ | |||
+ | When you need to run once your script and inspect its result in the console, you can do this as follows: | ||
+ | *make extra bit register, like "Debug step over bit" | ||
+ | *change run mode of the script being debugged - execute upon the register' | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | |||
+ | |||
debugging_complex_programs.txt · Last modified: 2022/01/15 20:50 by 127.0.0.1