Export translations
Перейти к:
навигация
,
поиск
Параметры
Группа
1-Wire
Allen Bradley DF1
API - Запись нового значения в регистр
API - Получение данных для графика
API - Получение данных для события
API - Получение данных о локальном времени
API - Получение лога регистров
API - Получение текущих значений регистров
API - Список блоков панелей
API - Список графиков
API - Список изображений
API - Список панелей
API - Список регистров
API - Список словарей
API - Список соединений
API - Список трендов
BACnet IP
Broadlink SP3S
Delta DVP
ModBus ASCII
ModBus RTU
Modbus RTU в виде custom protocol
ModBus TCP
Siemens PPI
Siemens S7 Communication
Test
Troubleshooting - Решение типовых проблем при работе в WebHMI
Аварии
Аннотация - функциональные возможности WebHMI
Битовые операции
Быстродействие при обмене данными
ВНИМАНИЕ! ДАННАЯ ВЕРСИЯ ВИКИ УСТАРЕЛА - см. docs.webhmi.com.ua
Внутренние регистры WebHMI
Демо-приложение для Android
Дополнительные СОМ порты
Доступ по ftp
Журнал регистров
Интеграция в другие системы
Использование MultiWan
Исторические графики
Как проверить уровень приема сигнала у 3G модема
Календарь
Назначение и применение
Настройка виртуального UART
Настройка связи с CDC-модемами на примере модема Huawei E3531
Настройка сетевых соединений
Обновление версии прошивки
Описание API
Описание внешних разъемов
Оптимизация производительности
Особенности работы с некоторыми модемами
Отладка сложных скриптов
Первое включение
Перевод на англ 2
Поддерживаемые протоколы
Подключение 3G модем ZTE K3806 Киевстар
Подключение WebHMI к Level2
Подключение внешних устройств
Подключение к Allen-Bradley MicroLogix 1200
Подключение к Kиевстар на примере модема ZTE MF100
Подключение к People.net
Подключение к S7-1200
Подключение к МТС Коннект
Подключение к ОВЕН160
Подключение к ПЛК с Codesys
Подключение к интернету через 3G модем
Полезные программы
Полезные советы
Пользовательские графики и тренды (Аналитика)
Пользовательские протоколы
Построение графиков в Level2
Пример доступа к данным из C/C++
Пример доступа к данным из Excel
Пример протокола ModBus ASCII
Пример протокола ModBus TCP
Примеры подключения к разным устройствам
Просмотр регистров по запросу
Работа с контроллером холодильного оборудования Danfoss AK-CC 550
Работа с регистрами
Рецепты
Сброс настроек
Синхронизация времени
Системные настройки и сервис
Скрипты
События
Соединения
Сравнение карт SD
Тренды
Удалённый сервисный доступ
Формирование отчетов
Функции управления соединениями
Функция Modbus/TCP сервер
Шаблоны дешбордов
Экраны
Язык
aa - Afar
ab - Abkhazian
ace - Achinese
ady - Adyghe
ady-cyrl - адыгабзэ
aeb - Tunisian Arabic
aeb-arab - تونسي
aeb-latn - Tûnsî
af - Afrikaans
ak - Akan
aln - Gheg Albanian
am - Amharic
an - Aragonese
ang - Old English
anp - Angika
ar - Arabic
arc - Aramaic
arn - Mapuche
arq - Algerian Arabic
ary - Moroccan Arabic
arz - Egyptian Arabic
as - Assamese
ase - American Sign Language
ast - Asturian
av - Avaric
avk - Kotava
awa - Awadhi
ay - Aymara
az - Azerbaijani
azb - تۆرکجه
ba - Bashkir
bar - Bavarian
bbc - Batak Toba
bbc-latn - Batak Toba
bcc - Southern Balochi
bcl - Bikol Central
be - Belarusian
be-tarask - Belarusian (Taraškievica orthography)
bg - Bulgarian
bgn - Western Balochi
bho - Bhojpuri
bi - Bislama
bjn - Banjar
bm - Bambara
bn - Bengali
bo - Tibetan
bpy - Bishnupriya
bqi - Bakhtiari
br - Breton
brh - Brahui
bs - Bosnian
bto - Iriga Bicolano
bug - Buginese
bxr - буряад
ca - Catalan
cbk-zam - Chavacano de Zamboanga
cdo - Min Dong Chinese
ce - Chechen
ceb - Cebuano
ch - Chamorro
cho - Choctaw
chr - Cherokee
chy - Cheyenne
ckb - Central Kurdish
co - Corsican
cps - Capiznon
cr - Cree
crh - Crimean Turkish
crh-cyrl - Crimean Turkish (Cyrillic script)
crh-latn - Crimean Turkish (Latin script)
cs - Czech
csb - Kashubian
cu - Church Slavic
cv - Chuvash
cy - Welsh
da - Danish
de - German
de-at - Austrian German
de-ch - Swiss High German
de-formal - German (formal address)
diq - Zazaki
dsb - Lower Sorbian
dtp - Central Dusun
dty - डोटेली
dv - Divehi
dz - Dzongkha
ee - Ewe
egl - Emilian
el - Greek
eml - Emiliano-Romagnolo
en - English
en-ca - Canadian English
en-gb - British English
eo - Esperanto
es - Spanish
et - Estonian
eu - Basque
ext - Extremaduran
fa - Persian
ff - Fulah
fi - Finnish
fit - Tornedalen Finnish
fj - Fijian
fo - Faroese
fr - French
frc - Cajun French
frp - Arpitan
frr - Northern Frisian
fur - Friulian
fy - Western Frisian
ga - Irish
gag - Gagauz
gan - Gan Chinese
gan-hans - Simplified Gan script
gan-hant - Traditional Gan script
gd - Scottish Gaelic
gl - Galician
glk - Gilaki
gn - Guarani
gom - Goan Konkani
gom-deva - Goan Konkani (Devanagari script)
gom-latn - Goan Konkani (Latin script)
got - Gothic
grc - Ancient Greek
gsw - Swiss German
gu - Gujarati
gv - Manx
ha - Hausa
hak - Hakka Chinese
haw - Hawaiian
he - Hebrew
hi - Hindi
hif - Fiji Hindi
hif-latn - Fiji Hindi (Latin script)
hil - Hiligaynon
ho - Hiri Motu
hr - Croatian
hrx - Hunsrik
hsb - Upper Sorbian
ht - Haitian Creole
hu - Hungarian
hy - Armenian
hz - Herero
ia - Interlingua
id - Indonesian
ie - Interlingue
ig - Igbo
ii - Sichuan Yi
ik - Inupiaq
ike-cans - Eastern Canadian (Aboriginal syllabics)
ike-latn - Eastern Canadian (Latin script)
ilo - Iloko
inh - Ingush
io - Ido
is - Icelandic
it - Italian
iu - Inuktitut
ja - Japanese
jam - Jamaican Creole English
jbo - Lojban
jut - Jutish
jv - Javanese
ka - Georgian
kaa - Kara-Kalpak
kab - Kabyle
kbd - Kabardian
kbd-cyrl - Адыгэбзэ
kg - Kongo
khw - Khowar
ki - Kikuyu
kiu - Kirmanjki
kj - Kuanyama
kk - Kazakh
kk-arab - Kazakh (Arabic script)
kk-cn - Kazakh (China)
kk-cyrl - Kazakh (Cyrillic script)
kk-kz - Kazakh (Kazakhstan)
kk-latn - Kazakh (Latin script)
kk-tr - Kazakh (Turkey)
kl - Kalaallisut
km - Khmer
kn - Kannada
ko - Korean
ko-kp - 한국어 (조선)
koi - Komi-Permyak
kr - Kanuri
krc - Karachay-Balkar
kri - Krio
krj - Kinaray-a
ks - Kashmiri
ks-arab - Kashmiri (Arabic script)
ks-deva - Kashmiri (Devanagari script)
ksh - Colognian
ku - Kurdish
ku-arab - كوردي (عەرەبی)
ku-latn - Kurdish (Latin script)
kv - Komi
kw - Cornish
ky - Kyrgyz
la - Latin
lad - Ladino
lb - Luxembourgish
lbe - лакку
lez - Lezghian
lfn - Lingua Franca Nova
lg - Ganda
li - Limburgish
lij - Ligurian
liv - Livonian
lmo - Lombard
ln - Lingala
lo - Lao
loz - Lozi
lrc - Northern Luri
lt - Lithuanian
ltg - Latgalian
lus - Mizo
luz - Southern Luri
lv - Latvian
lzh - Literary Chinese
lzz - Laz
mai - Maithili
map-bms - Basa Banyumasan
mdf - Moksha
mg - Malagasy
mh - Marshallese
mhr - Eastern Mari
mi - Maori
min - Minangkabau
mk - Macedonian
ml - Malayalam
mn - Mongolian
mo - молдовеняскэ
mr - Marathi
mrj - Western Mari
ms - Malay
mt - Maltese
mus - Creek
mwl - Mirandese
my - Burmese
myv - Erzya
mzn - Mazanderani
na - Nauru
nah - Nāhuatl
nan - Min Nan Chinese
nap - Neapolitan
nb - Norwegian Bokmål
nds - Low German
nds-nl - Low Saxon
ne - Nepali
new - Newari
ng - Ndonga
niu - Niuean
nl - Dutch
nl-informal - Nederlands (informeel)
nn - Norwegian Nynorsk
nov - Novial
nrm - Nouormand
nso - Northern Sotho
nv - Navajo
ny - Nyanja
oc - Occitan
olo - Livvi-Karelian
om - Oromo
or - Oriya
os - Ossetic
pa - Punjabi
pag - Pangasinan
pam - Pampanga
pap - Papiamento
pcd - Picard
pdc - Pennsylvania German
pdt - Plautdietsch
pfl - Palatine German
pi - Pali
pih - Norfuk / Pitkern
pl - Polish
pms - Piedmontese
pnb - Western Punjabi
pnt - Pontic
prg - Prussian
ps - Pashto
pt - Portuguese
pt-br - Brazilian Portuguese
qu - Quechua
qug - Chimborazo Highland Quichua
rgn - Romagnol
rif - Riffian
rm - Romansh
rmy - Romani
rn - Rundi
ro - Romanian
roa-tara - tarandíne
ru - Russian
rue - Rusyn
rup - Aromanian
ruq - Megleno-Romanian
ruq-cyrl - Megleno-Romanian (Cyrillic script)
ruq-latn - Megleno-Romanian (Latin script)
rw - Kinyarwanda
sa - Sanskrit
sah - Sakha
sat - Santali
sc - Sardinian
scn - Sicilian
sco - Scots
sd - Sindhi
sdc - Sassarese Sardinian
sdh - Southern Kurdish
se - Northern Sami
sei - Seri
ses - Koyraboro Senni
sg - Sango
sgs - Samogitian
sh - Serbo-Croatian
shi - Tachelhit
shi-latn - Tašlḥiyt
shi-tfng - ⵜⴰⵛⵍⵃⵉⵜ
si - Sinhala
sk - Slovak
sl - Slovenian
sli - Lower Silesian
sm - Samoan
sma - Southern Sami
sn - Shona
so - Somali
sq - Albanian
sr - Serbian
sr-ec - Serbian (Cyrillic script)
sr-el - Serbian (Latin script)
srn - Sranan Tongo
ss - Swati
st - Southern Sotho
stq - Saterland Frisian
su - Sundanese
sv - Swedish
sw - Swahili
szl - Silesian
ta - Tamil
tcy - Tulu
te - Telugu
tet - Tetum
tg - Tajik
tg-cyrl - Tajik (Cyrillic script)
tg-latn - Tajik (Latin script)
th - Thai
ti - Tigrinya
tk - Turkmen
tl - Tagalog
tly - Talysh
tn - Tswana
to - Tongan
tokipona - Toki Pona
tpi - Tok Pisin
tr - Turkish
tru - Turoyo
ts - Tsonga
tt - Tatar
tt-cyrl - Tatar (Cyrillic script)
tt-latn - Tatar (Latin script)
tum - Tumbuka
tw - Twi
ty - Tahitian
tyv - Tuvinian
tzm - Central Atlas Tamazight
udm - Udmurt
ug - Uyghur
ug-arab - Uyghur (Arabic script)
ug-latn - Uyghur (Latin script)
uk - Ukrainian
ur - Urdu
uz - Uzbek
uz-cyrl - ўзбекча
uz-latn - oʻzbekcha
ve - Venda
vec - Venetian
vep - Veps
vi - Vietnamese
vls - West Flemish
vmf - Main-Franconian
vo - Volapük
vot - Votic
vro - Võro
wa - Walloon
war - Waray
wo - Wolof
wuu - Wu Chinese
xal - Kalmyk
xh - Xhosa
xmf - Mingrelian
yi - Yiddish
yo - Yoruba
yue - Cantonese
za - Zhuang
zea - Zeelandic
zh - Chinese
zh-cn - Chinese (China)
zh-hans - Simplified Chinese
zh-hant - Traditional Chinese
zh-hk - Chinese (Hong Kong)
zh-mo - 中文(澳門)
zh-my - 中文(马来西亚)
zh-sg - Chinese (Singapore)
zh-tw - Chinese (Taiwan)
zu - Zulu
qqq - Message documentation
Format
Экспорт для оффлайнового перевод
Экспорт в родном формате
{{DISPLAYTITLE:Optimizing performance}}<languages/> To understand the principles of WebHMI operation, let's analyze how its kernel works. Schematically, the structure of the core of the system can be represented as follows: [[Файл:WebHMI-диаграма.png|230px]] The kernel works cyclically. This means that all actions are performed sequentially. If delays occur at some stage, this affects the execution time of the entire cycle. Let's look at each of the blocks in this diagram. == Configuration read == Immediately after the system is booted up, the project is loaded into the main memory. At that moment, the values of all volatile registers are reset to zero, the state of all events is set to 'not executed'. If the user makes any change to the settings of registers, connections, events, scripts, etc. the kernel re-reads the configuration after the end of the current cycle. All the values of the registers will be reset, events will also be interrupted. Therefore, changing the configuration of the project during commercial operation can cause interruption of events and resetting of registers that are in energy-dependent memory. We do not recommend changing the project 'on the fly' without extreme need. When the project settings are read, the kernel enters the main loop. == Writing new values to registers == At the beginning of the cycle, the new values '''are written to the registers'''. The system has a special queue for writing new values to the registers. There are 2 ways to write data to the register - through the API and through scripts. In both cases, the recording does not occur when the request comes (because the system may not be ready for this, for example, the RS-485 is already exchanging with the PLC) and later, at the appropriate time. A write request is sent to the queue. All write requests will be executed at the beginning of the next main loop. == Registers read == Further, the registers are read from external devices and internal registers of WebHMI. Registers are read in groups. Grouping occurs by their connection. For example, if the project has a connection to a Delta PLC, Siemens PLC and internal WebHMI registers, the reading will look like this: 1. All registers from Delta PLCs are read. <br> 2. All registers from Siemens PLC are read. <br> 3. All internal registers of WebHMI are read <br> Internal WebHMI registers are always read last (since they contain registers C0, C1, C2 ... in which the read errors from the remaining connections are stored). Immediately after reading, the necessary value transformations (multiplication, constant additions, casting, etc.) take place. If there is a stabilization pause for any of the connections, then there will be a corresponding pause before reading the register group of this connection. This is sometimes necessary for the stable operation of heterogeneous devices on one RS-485 bus. Without this pause, some devices may not be able to determine the start of the message frame and skip the first packet to read the first register. Also, the connections have a Timeout setting. This is the time that the system will wait for a response from the devices on its request. If the devices did not respond within the specified time period or answered the entire packet of data, the system will assume that the register has not been read. Its value will be set to -1, and the register status to invalid. This means that if there is no connection with one of the external devices, the total polling time (the minimum length of the main loop) will increase by Timeout × The number of registers in this connection. Here is an example. We have a connection to the Delta SX2 PLC via ModBus RTU. We read from it 5 registers at a speed of 115200. Timeout is set to 100 ms. The average time for reading all five registers is 30 ms (you can see it in the internal register of WebHMI T1). If the connection to the PLC is lost for any of the reasons, then the average read time of all five registers will theoretically increase to 5 × 100 ms = 500 ms (and in practice will be approximately 525 ms). This means that if there is polling of an unconnected device in the project, then this will slow the entire cycle for a significant amount of time. If it is necessary to minimize this delay, then it is necessary to maximize the exchange rate and reduce Timeout and Stabilization pause. But the best thing is to either reconnect with the device or disconnect this connection in the settings. == Running scripts == After the registers have been read, the kernel executes the scripts. Scripts (or programs) are carried out very quickly and there should not be delays here with a reasonable number and complexity of scenarios. The only feature that you should pay attention to is the difference in the operation mechanism of the Set and Write operations. The '''Set''' operation will change the value of the specified register immediately, at the same place in the main loop. And it will only change the value in the kernel's RAM. The new value will not be written to external devices and will only be available until the end of the current cycle. The operation '''Write''' does almost everything as Set does with the only difference that it adds a command of writing a new value to the write queue. And at the beginning of the next cycle, this value will be written to the appropriate register of the external device. Note that if there is a condition in the script and any register from this condition has not been read in the current loop, then this condition will not be handled. And, accordingly, actions from this condition will not be performed. == Calculating register states == By this point in the main loop, the values of all the registers have already been computed and will not change later. Therefore, it is at this point that states (invalid / disabled / normal / warning / alert) are calculated for each register . == Processing Events == After all data is collected and prepared, the mechanism for identifying and processing events is triggered. Event processing starts with checking the condition of the event. Similar to scripts, if any register from the condition was not read in the current loop, then this condition will not be handled. And accordingly the whole event will not be processed. If the event does not have an extension in time, then the condition for its occurrence is checked in each cycle. And each time this condition is met, the actions for that event will be executed. In each subsequent cycle, if the condition is fulfilled again, then this will be a new occurrence of the event and the actions will be performed again. If the event has a length in time, then it has an execution state. This is the flag that tells the kernel that the condition is met. Such an event can start executing in one cycle and will end in the other. It can last as long as you like (but with any change to the configuration of the WebHMI project, this flag will necessarily be reset). When the condition of the event start is fulfilled, the execution flag is set to true. If the end condition (if it is set) or when the condition of the beginning is not fulfilled (if the end condition is not specified), the flag is reset to false. While this flag is true, all actions for this event are executed. This flag can also be read from internal WebHMI registers at ESx addresses, where x is the event ID. Note that the first "true" value will be calculated in the scan followed the one in which this value was set to true. Besides the actions available for events, there is a record of information about the event in the database. It should be understood that this operation is resource-intensive. Therefore, it is recommended to write data as rarely as possible. And collect only the necessary data. It makes no sense to write all the registers to the database in each cycle, if it is enough to collect data on the five required registers with an interval of 5 seconds. Also, enhancing too much data details will likely lead to a heavy load on the SD card and its increased wear. So follow the common sense in data collection and gather only the data that is really needed in your project. One of the options when saving event data is to record a slice of register values every N seconds. In fact, it is implemented so that the recording will occur no more often than every N seconds from the last record in the database. Here it is necessary to explain the peculiarity of the operation of this interval. It is best to do this with an example. Example. The kernel reads 150 ModBus registers, the average cycle length is 1.3 seconds. The event is set to record data every 5 seconds. Assume that the event is executed for the first time in T + 0.0 seconds. The data was written to the database also in T + 0.0 seconds. In the next cycle, the event is still running. The time from the last recording is T + 1.3 seconds. 1.3< 5 sec. so writing to the database does not happen. <br> In the next event cycle, the event is still running. The time since the last recording is T + 2.6 seconds. 2.6 < 5 sec. so writing to the database does not happen. <br> In the next cycle, the event is still running. The time from the last recording is T + 3.9 seconds. 3.9 < 5 sec. so writing to the database does not happen. <br> In the next cycle, the event is still running. The time from the last record is T + 5.2 seconds. 5.2 > 5 sec. so the record in the database will occur. Next, the system will compare the time with the moment T + 5.2. Note that the actual time between records will be 5.2 seconds and not 5. Because the system displays the time with a second accuracy, this can cause the time between records to be displayed as 6 seconds, and for some variations even 7 seconds (for example, the first record was in T + 0.9 and the second in T + 6.1). I.e. due to the fact that the length of the cycle can be unstable, then the actual data recording interval will also depend on this length. The system will behave optimally if the specified interval of the interrogation of devices (Communication interval) exceeds the actual length of the cycle and the recording in the database is conducted with a multiple interval (Communication interval). == Preparing register values for the API == After processing the events, the kernel will prepare a list of all the registers, their states and values, and pass it to the API. After that, the responses from the API about the current values of the registers will contain the data obtained in the current cycle. == Writing values to the database == At this stage of the cycle, the current values of the registers are written to the log. Only those registers for which the corresponding option is included are written to the log. If the option to record graphs for the register is enabled, then data is recorded for plotting. Recording to an SD card is a slow operation. Therefore, recording a large number of values with a high frequency of changes can take a significant amount of time and system resources. It also consumes an SD card resource. Therefore, it is recommended to write to the log only those registers that are really needed. We also recommend writing them not too often. Recording 10-20 parameters every second can significantly load the system, reduce the responsiveness of the interface, increase the cycle length. == Pause == After all the operations have been completed, the system determines how much time was actually spent for the current cycle. If this time is less than the Communication interval setting, the system will pause for the difference '''[Communication interval - actual time]''' so that the total cycle length is exactly the time specified in the Communication interval. 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. <br> 2. 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. <br>
Навигация
Персональные инструменты
русский
127.0.0.1
Обсуждение для этого IP-адреса
Войти
Пространства имён
Служебная страница
Варианты
Просмотры
Ещё
Поиск
Навигация
Заглавная страница
Свежие правки
Случайная статья
Справка
Инструменты
Спецстраницы
Версия для печати