User Tools

Site Tools


faq

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
faq [2021/08/27 10:00]
emozolyak [Screen text widget]
faq [2022/01/14 14:40] (current)
127.0.0.1 ↷ Links adapted because of a move operation
Line 3: Line 3:
 ===== Screens, Dashboard visualization ===== ===== Screens, Dashboard visualization =====
  
 +==== Responsive design with screens ====
 +
 +  Question: Is it possible to make a responsive visualizatoin with WebHMI? 
 +
 +Starting from 3.6 version and [[screens?s[]=screens#screens|screens]] it is possible to make responsive visualization with WebHMI.
 +
 +Please follow the screen documentaion page to make an idea of its possibiliies. 
 +
 +E.g. if your screen looks like this one on the desktop large monitor:
 +{{ network:hvac_full_screen.png?direct&800 |}}
 +
 +then on the mobile device it will fold in into these:
 +
 +{{ network:widget_swipe_hvac.gif }}
 +
 +If you want your widgets with dashboard to take all available space of the widget, set his option: 
 +
 +{{ network:panel_contained_option_red_box.png?direct&600 |}}
 +
 +Other project parts like graphs etc. will also adjust their size:
 +
 +{{ network:graph_mobile_view.png?direct&400 |}}
 ==== Screen text widget ==== ==== Screen text widget ====
 === Colorizing register values into custom colours === === Colorizing register values into custom colours ===
  
-Q: In my screen widget I want the register values have custom colour.+  Question: In my screen widget I want the register values have custom colour. I set a color for them, but still  
 +  they are black/white colours (depending on theme) 
 + 
 +<WRAP center round tip 100%> 
 +The register values in the WebHMI are colourized using this rule - it is either default value color, or the color defined in the register [[registers?s[]=state#states_tab|STATE]]. There is a default register value style which overrides text widget styles for values.  
 +So, to make your register value of a desired colour, set a STATE for the register with the colour you want.  
 + 
 +</WRAP> 
 +{{ network:text_widget_reg_value_colors.png?direct&600 |}} 
 + 
 +===== Performance issues ===== 
 +==== My WebHMI is slow ==== 
 +There are many reasons why your device may slow down, a "disable function & try" method should be applied to detect the source of this problem.  
 + 
 +Below a summary of the possible causes is provided: 
 + 
 +== Screens / Dashboards == 
 + 
 +  * 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 , trends with long time window etc. ) , normal dashboard is about tens of KB, not MB! 
 +  * Set appropriate refresh time in the settings. 
 +  * 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. 
 + 
 +=== Scripts === 
 + 
 +  *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 UpdReg(), which writes to register only if value has changed. 
 + 
 +=== Communication ===  
 +  *Group register to read on external device and use group reading. 
 +  *Decrease timeout and tries in external connections  if it possible. Use auto-drop&try for not available connections. 
 +  *Organize and set different reading periods for variables. 
 +  *Keep the actual T1 time less than system scan set in the settings. this will give more "room" for OS' background processes. 
 + 
 +=== Writing to log ===  
 +  *Minimize logging many registers to DB, 
 +  *Set appropriate log speed for the registers.check you don't have many events logged each scan.
  
 +=== Development process ===
 +  *Keep the number of registers in the project below 2-3K
 +  *During development, keep track of the Load Average parameter it should be below 1  (but can have short bursts above this value, which ought to fall soon)
 +  *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..)
 +  *In the comm. log, you can set TRACE level and see what times each operation takes (each connection, script, communication with device etc.), checking timestamps