WebHMI Docs

User Tools

Site Tools

multiplexing_connections_technique

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
multiplexing_connections_technique [2021/08/04 15:06] – ↷ Page name changed from performance_of_data_exchange to multiplexing_connections_technique emozolyakmultiplexing_connections_technique [2023/02/22 13:15] (current) – emozolyak
Line 5: Line 5:
 In a __very large systems__, there are sometimes hundreds of devices (usually identical), with hundreds of even thousands of registers in each of them. If all these parameters were declared in a WebHMI register list, this would heavily load the system, increase scan time, increase processing time etc.  In a __very large systems__, there are sometimes hundreds of devices (usually identical), with hundreds of even thousands of registers in each of them. If all these parameters were declared in a WebHMI register list, this would heavily load the system, increase scan time, increase processing time etc. 
  
-{{::many_devices.png?direct&400|}}+{{network:many_devices.png?direct&400|}}
  
 In fact, each device has only few parameters to monitor - regarding object being monitored itself, while the rest (and most) are just settings like delays, hysteresys, scaling coefficients, sensors types and so on, being rarely accessed. In fact, each device has only few parameters to monitor - regarding object being monitored itself, while the rest (and most) are just settings like delays, hysteresys, scaling coefficients, sensors types and so on, being rarely accessed.
Line 15: Line 15:
 This task can be easily built with WebHMI tools - dashboards and scripts. The idea is illustrated in the below figure: This task can be easily built with WebHMI tools - dashboards and scripts. The idea is illustrated in the below figure:
  
- {{::optimize_option_1.png?direct&800|}}+ {{network:optimize_option_1.png?direct&800|}}
  
 Each device (temperature controller) has two main parameters: process value and setpoint, that's enough for process control. There is also a bunch of "unwanted for constant scan" setting registers 1..100. We want to access "unwanted" registers on-demand, not interfering main scan where more importand data is placed.  Each device (temperature controller) has two main parameters: process value and setpoint, that's enough for process control. There is also a bunch of "unwanted for constant scan" setting registers 1..100. We want to access "unwanted" registers on-demand, not interfering main scan where more importand data is placed. 
Line 22: Line 22:
   *Listbox is linked with **script(s)**, which does the following:   *Listbox is linked with **script(s)**, which does the following:
     *enables connection     *enables connection
-    *sets respective network address for the connection using **SetConnectionAddress** function+    *sets respective network address for the connection using [[https://docs.webhmi.com.ua/control_connections?s[]=setconnectionaddress| SetConnectionAddress]] function
     *switches visibility bit to temporarily hide control box - this is __to avoid conflict__ in a multi-user system. After timer-out the connection is disabled again, the timer restarts if user activity detected (modifying values )     *switches visibility bit to temporarily hide control box - this is __to avoid conflict__ in a multi-user system. After timer-out the connection is disabled again, the timer restarts if user activity detected (modifying values )
  
multiplexing_connections_technique.1628089573.txt.gz · Last modified: 2021/08/04 15:06 by emozolyak
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki