Правильный подход обмена данных с устройствами через COM-порт. Целостность пакетов и производительность обмена26.02.2018, 23:52. Показов 21327. Ответов 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 или через контекстное меню Обмена информации через сокеты Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
сукцессия 30. Фосфорный и азотный замки по "честному" закону лимитирования Либиха
anaschu 16.07.2026
Основные достижения за последние дни
1. Механизм отложенного высвобождения фосфора
Добавлен специальный пул для медленного разложения меланизированных гиф ЕСМ
Реализована разная скорость. . .
|
Запрет пометки на удаление и отмены проведения
Maks 16.07.2026
Алгоритм из решения ниже реализован на нетиповом документе "ПутевойЛист" разработанного в КА2.
Задача: запретить помечать на удаление и отменять проведения путевого листа при условии, если он сдан. . .
|
Как надо было делать правильно - вообще не слушать ИИ, его дело - текст.
Hrethgir 15.07.2026
А вообще надо было делать не так, чтобы не исправлять ошибку https:/ / www. cyberforum. ru/ blogs/ 223907/ 10996. html , правильно было : удалил кнопку, а потом добавил её.
Всё это стресс конечно. Почему?. . .
|
Знаете, от чего появляется стресс?
kumehtar 15.07.2026
Стресс появляется оттого, что вы, зная как поступить правильно, делаете наоборот.
Ларри Уингет
|
|
Нас бьют, а мы крепчаем? Какая чушь!
kumehtar 15.07.2026
Вот это вот бытующее мнение, что человек меняется только под действием проблем, всегда считал вредоносным. Поверь, от проблем у людей появляются не изменения, а нервное расстройство и ПТСР. А. . .
|
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным?
anaschu 12.07.2026
Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров
В текущей версии модели успешно реализован ключевой механизм. . .
|
сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию.
anaschu 12.07.2026
Анализ соответствия модели требованиям
Реализованные компоненты:
Механизм закисления почвы через протонную помпу
Конкуренция между типами микориз
pH как триггер сукцессии
C/ P соотношение. . .
|
Сукцессия 26. Мат модель создана.
anaschu 12.07.2026
Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .
|