User Tools

Site Tools


This is an old revision of the document!

Frequently Asked Questions (FAQ)

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 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:

then on the mobile device it will fold in into these:

Screen text widget

Colorizing register values into custom colours

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)

The register values in the WebHMI are colourized using this rule - it is either default value color, or the color defined in the register 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.

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.


  • 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.


  • 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