Правильный подход обмена данных с устройствами через COM-порт. Целостность пакетов и производительность обмена26.02.2018, 23:52. Показов 21331. Ответов 71
Метки нет (Все метки)
Приветствую вас, коллеги!
Хочу с вами посоветоваться, ибо мне кажется, что я делаю это не совсем правильно, либо что-то не учёл... Делаю обмен данными с устройством через COM-порт (RS-232) по алгоритму: послал команду в порт (через .Write(...)), поставил задержку (Threading.Sleep(200)), читаю ответ (через .Read(...)). И вот тут меня смущает эта самая задержка. Если ответные пакеты приходят большие (ну например более 60 байтов), то что бы вычитать весь буфер, этой задержки как буд-то не хватает, пакет получаю не весь. Если увеличиваю задержку, то буфер весь вычитывается, однако, во-первых, буфера могут быть разной длины, и для каждого так подбирать задержки - не реально, во-вторых, если с устройством есть возможность обмениваться на разных скоростях (бод), это вообще дур-дом и всякая актуальность, например, выбора более высокой скорости обмена теряется, т.к. задержки будут одинаковыми, если их так железно задавать... В-третьих, когда такая функция обмена, с железно заданным Sleep'ом (подобранным на вскидку, чтоб не потерять большие пакеты), в цикле, например, ведёт обмен, то для более мелких пакетов, такая задержка, опять же, становится не актуальной, т.к. увеличивается драгоценное время простоя, и обмен происходит дольше, чем мог бы быть... Вот по этому я и задаюсь вопросом: как в таком случае правильно следует поступать? Не ужели чем длиннее ответный пакет, тем дольше его нужно ждать, чтоб он вычитался? Как избежать таких диких задержек? У кого был подобный опыт с обменом по СОМ-порту с устройствами, подскажите, пожалуйста, или поделитесь идеями, кто хотя бы понял суть вопроса. P.S. слышал что-то про подход асинхронного чтения данных из порта, но пока не понял что это и с чем это едят, и мой ли это вообще случай. Если да, то расскажите про такой подход, кто в курсе вообще. Только по понятнее пожалуйста, с примерами, если можно, а то про асинхронные приёмы работы пока вообще не в теме... Особо не доводилось использовать.
0
|
|
| 26.02.2018, 23:52 | |
|
Ответы с готовыми решениями:
71
Организация обмена данными через LPT-порт Функция для обмена HEX данными через COM порт Синхронизация обмена данных через LiFi |
|
|
|||
| 07.04.2018, 18:54 | |||
|
Добавлено через 1 минуту
0
|
|||
|
|
||
| 07.04.2018, 18:59 | ||
|
Rius, кстати, было бы интересно как-нибудь декомпилировать C-шную библиотеку для обмена и посмотреть, как там это реализовано. Я вот сейчас пишу программу, но там весь обмен как раз в C-шной либе скрыт, а я только через импортом пользуюсь методами оттуда.
Добавлено через 1 минуту
0
|
||
|
|
||
| 07.04.2018, 19:00 | ||
|
Если библиотека сделана по канонам, то скорее всего оно описано в известном документе Serial Communication in Win32.
Добавлено через 1 минуту
0
|
||
|
|
|||
| 07.04.2018, 19:05 | |||
|
Хотя он больше для интереса, в общем я просто беру и использую импорт из тех либ. Добавлено через 1 минуту
0
|
|||
|
|
|
| 07.04.2018, 19:09 | |
|
Чтение из COM-порта, странная ошибка ?
Добавлено через 2 минуты Мне всё это пришлось выдумывать из-за приборов с HART, которые работают на 1200 бодах. Если пакет в ответ не пришёл, напрасно потрачена секунда или две. А если надо проверить наличие 15-ти приборов на линии, это ппц...
0
|
|
| 07.04.2018, 19:13 [ТС] | ||
|
У моей программы, общающейся с устройством, есть как одиночные команды, с одиночными ответными буферами на них, так и команды-запросы, на которые устройство циклом в 500, 2000, и даже 11000 итераций выдаёт данные, ну скажем, по 180-250 байт за одну итерацию. И вот когда пользователю нужно считать из устройства его базу, например, в 6000, или тем более в 11000 (это пока максимум) полей (строк), раньше в алгоритме обмена со слипом, это занимало около 40 минут... +/- А вот с методом двух тайм-аутов это время уже сократилось до 5 минут (тоже примерно. точно сейчас не припомню). Но при этом методе, как уже неоднократно упоминал, на ПК разных мощностей, эти показатели разнятся... В общем в моём случае, пользователям (хотя скорее больше моему начальству) не особо хочется долго ждать выполнения чтения столь не малого кол-ва данных. Особенно, если за время работы с программой, это нужно повторять неоднократно...
0
|
||
|
|
|
| 07.04.2018, 19:15 | |
|
Rius, нет, значит не там... Там всего один вариант, а я точно помню, что экспериментировал по разному. Сейчас залез в исходники, остался только метод с комментом Вариант №1, остальные я стер. Попробую поискать, точно помню, что как минимум три варианта было. И да, ваш вариант я пробовал. Он работает побыстрее чем мой, но опять же, нет той стабильности. А мне это важно, мне за это деньги платят)))
0
|
|
| 07.04.2018, 19:22 [ТС] | ||
|
И в принципе, согласно протоколу, в ответной посылке на все команды, второй байт - это и есть длина пакета.
0
|
||
|
|
||||||
| 07.04.2018, 19:25 | ||||||
|
Rius, да, кстати, вот кусок кода из промышленной либы (на шарпе, которая использует импорт). Как видите, при работе с портом многие не гнушаются использованием слипов)))
0
|
||||||
|
|
||
| 07.04.2018, 19:33 | ||
|
0
|
||
| 07.04.2018, 19:35 | |
|
0
|
|
| 07.04.2018, 19:38 [ТС] | ||
|
0
|
||
|
|
||
| 07.04.2018, 19:41 | ||
|
insite2012, да я только за. Пусть ТС пробует по-вашему. С известным размером пакета сам бог велел.
0
|
||
|
|
|||||||
| 07.04.2018, 19:49 | |||||||
|
Cha1000000, вы все-таки попробуйте для начала просто подход, цикл в 10 итераций с задержкой по 50 мс и проверкой буфера порта при каждой итерации. В принципе, это должно работать как и обычный таймаут в 500 мс для порта.
Типа того что ниже. И потом уже посмотрите, насколько дольше это работает.
0
|
|||||||
|
|
||
| 07.04.2018, 19:50 | ||
|
Он работает значительно быстрее (если по ссылке не разберетесь могу скинуть рабочие исходники).
2
|
||
|
|
|
| 07.04.2018, 19:57 | |
|
0
|
|
| 07.04.2018, 19:57 | |
|
Виртуальный COM-порт на STM32, скорость обмена.
COM-порт, работа с двумя формами и одним буфером обмена Запретить вставку текста в TEdit из буфера обмена через Ctrl+V или через контекстное меню Обмена информации через сокеты Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических
anaschu 18.07.2026
Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано
Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .
|
сукцессия 30. Массив проверяющих друг друга моделей
anaschu 18.07.2026
Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0)
Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона
Уважаемые коллеги!
В продолжение. . .
|
Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины.
anaschu 18.07.2026
ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии
Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .
|
Текстовый слайдер с нумерацией страниц и кроссбраузерность.
russiannick 18.07.2026
Один мой друг написал текстовый слайдер с нумерацией страниц. Сегодня я расскажу как он умудрился подружить его с кроссбраузерностью.
Очевидно сложно угодить с шириной каждому браузеру. Один крадет. . .
|
|
Грибы - это мемы, дерево - это человек. Применение микоризной модели к теории меметики Докинза.
anaschu 18.07.2026
Меметический изоморфизм теории «всего»: Грибная сукцессия как модель эволюции идей Докинза
Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а универсальную. . .
|
Грибы - это корпорации, деревья - это государства. Механизм массонского захвата власти
anaschu 18.07.2026
Макроэкономический изоморфизм теории «всего»: Грибная сукцессия как модель транснационального капитализма
Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а. . .
|
Расчёт периметра прямоугольника по координатам вершин
Maks 18.07.2026
Решение задачи по прикладной информатике средствами 1С.
Задача:
Вычислить периметр прямоугольника, заданного координатами своих вершин на плоскости.
Решение:
Создан документ со следующими. . .
|
Подсчёт частоты трёхбуквенных слов в тексте
Maks 18.07.2026
Решение задачи по прикладной информатике средствами 1С.
Задача:
Выясните, сколько раз в предложенном тексте встречается каждое трехбуквенное слово.
Решение:
Создан документ с единственным. . .
|