Differences

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

--- performance_optimization [2018/12/10 12:00] – created emozolyak
+++ performance_optimization [2021/01/16 09:54] – [General rules for optimizing your projects] emozolyak
@@ Line 106: / Line 106: @@
 This means that if the actual cycle time is greater than the Communication interval, the system will not pause and will not be able to poll the devices with the specified periodicity.
-If it is necessary to "fit" the specified interval, then there are several ways of optimization: 1. Increase the speed of exchange on the RS-485, RS-232 buses. The speed of 9600 is too slow for a lot of data. We recommend selecting a speed of 115200 and higher.
+If it is necessary to "fit" the specified interval, then there are several ways of optimization:
-. If there are a lot of registers and not all need to be polled in each cycle, then you can specify a larger poll interval for less important registers. This will offload the system and data buses.
+  -Increase the speed of exchange on the RS-485, RS-232 buses. The speed of 9600 is too slow for a lot of data. We recommend selecting a speed of 115200 and higher.
+  -If there are a lot of registers and not all need to be polled in each cycle, then you can specify a larger poll interval for less important registers. This will offload the system and data buses.
+===== General rules for optimizing your projects =====
+At the time When the webhmi was ,
+  -Use screens wherever is possible for visualisation, and use dashboards as a part of screens for graphic part, which can not be done with the screens.
+  -Avoid using bulky DASHBOARDS (too rich in elements, having heavy-weight pictures etc. ), "normal" dashboard is about tens of KB, not MB!
+  -Avoid using many scripts (like dashboards scripts or upon change value scripts). The better way is using a few big scripts or scripts with libraries  instead of a lot of small scripts (each script takes some os environment)
+  -Run scripts upon changing value, minimize the number of scripts, running in each scan
+  -Minimize "WriteReg" Lua instructions in each scan.  It is better to use wrapping function UpdateReg(), which write to register only if value has changed.
+  -Group register to read on external device and use group reading.
+  -Set appropriate timeout and tries in external connections  E.g. if the device has common timeout of 30 ms, set it about 40 ms. If the deivce gets lost, with bigger timeout of 100 ms, if its possible. Use auto-drop&try for not available connections.
+  -Organize and set different reading periods for variables.
+  -Use event communication.
+  -Set appropriate screen refresh time.
+  -Keep the number of open tabs minimal for the current sessions. If you need multiple tabs, use auto-close session checkbox to prevent unattended access.
+  -During development, keep parameter Load Average below 1
+  -Avoid making simultaneous changes at once, like turning OFF-ON many regs, connection, scripts etc. Use save & apply feature of the latest fw. (apply all changes at once, instead of creating a queue for changes..)
+  -Minimize logging many registers to DB, set appropriate log speed for them.
+  -Keep the number of registers in the project below 2-3K
+<code lua>
+function UpdReg(reg, new_value)
+    local cur_value = R(reg)
+    if (not cur_value) or (cur_value == new_value) then
+        return
+    else
+        W(reg, new_value)
+    end
+end
+</code>