From OpenSCADAWiki
Enter a message name below to show all available translations.
Found 3 translations.
| Name | Current message text |
|---|---|
| h English (en) | == {{Anch|Notes|Notes}} == Communications via the serial interfaces have a number of features. The most important feature is the criterion for the end of the message and the waiting time of this criterion. In some protocols, such a criterion is a sign of the end or the specified message size. In other protocols, such a criterion is no data in the input stream for a specified time — the symbol time. In both cases, the criterion waiting time, or the symbol, is a crucial and strongly affects the overall exchange time and the data integrity. Consequently, the smaller this time, the better if you have no loss the data tail. Here the problem of hardware and its drivers latency happens. |
| h Russian (ru) | == {{Anch|Notes|Замечания}} == Коммуникации через последовательные интерфейсы имеют ряд особенностей. Наиболее важной особенностью является критерий окончания сообщения и время ожидания этого критерия. В одних протоколах таким критерием является признак окончания или указанный размер сообщения. В других протоколах таким критерием является отсутствие данных во входном потоке в течение указанного времени — время символа. В обоих случаях время ожидания критерия, или символа, является ключевым и сильно сказывается на общем времени обмена. Следовательно, чем меньше это время тем лучше. Тут и возникает проблема латентности оборудования и его драйверов. |
| h Ukrainian (uk) | == {{Anch|Notes|Зауваження}} == Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу — час символу. У обох випадках час очікування критерію, або символу, є ключовим та сильно впливає на загальний час обміну і цілісність даних. Відповідно, чим менше цей час тим краще, якщо відсутні втрати хвоста даних. Тут і виникає проблема латентності обладнання та його драйверів. |