Класс для COM-порта с поддержкой событий

Доброго. Мне нужен класс для работы с COM-портом с поддержкой событий.

У меня есть вариант: Serial Port Communication in Excel (VBA). Я его использую в Excel. Проблема в том, что нужно ручками регулировать время между командой и ответом, чтобы гарантировано принять данные во входной буфер. Хотелось бы иметь событие OnReceive(), которое основано на WaitCommEvent(). Без событийного решения трудно реализовать оптимальный по скорости алгоритм работы с устройствами. Мне нужно с определённой частотой читать данные и желательно получать их по мере заполнения входного буфера нужной посылкой.

Можно ли что-то такое сделать на vb6? Мне не нужны сторонние решения в готовом виде (ActiveX, dll и т.п.). Нужно всё реализовать на макросах в таблице.

0

Сообщение от уни Ты даёшь совет как мне красивее и правильнее доставать байты из буфера?

Нет. Я даю правильное, прямое решение твоей проблемы. Кто-нибудь потом также будет мучиться с этим кодом, найдет мой пост и решит проблему. Я совершенно точно знаю почему твой код не работает, а ты не знаешь и еще пытаешься что-то мне доказать. Разве это не глупо?

Сообщение от уни У меня уже всё работает.

Нет, это не будет работать, не нужно дезинформировать людей. Будет работать только когда чтение пройдет внутри ReadFile (вернет не NULL), считай практически никогда; эквивалентно вызову синхронной функции, т.е. эффекта от асинхронности нет никакого. Вот поэтому у тебя и синхронный вызов работает без проблем, а асинхронный не работает.

0

Я эффект замеряю статистически как разницу во времени при разных подходах. Монитор показывает дамп обмена по последовательному порту.

У меня есть прибор, который шлёт посылки с частотой 10 Гц без команд. Я должен их гарантировано принять. Код выше, который я нашёл в сети, не имеет прямого метода ожидания приёма, поэтому для гарантированного приёма мне приходилось обходить недостаток функционала. Самый простой способ - добавить задержку в 1-2 интервала между посылками и читать буфер. Это работало, но я не мог достичь скорости 10 Гц из-за искусственных задержек.

Поэтому я пришёл к более сложному методу с флагами и дополнительными winapi-функциями. Написал программу на с++ и сравнил в тех же условиях разницу по времени между запросом и ответом. На картинке выше изображен результат работы с другим прибором, у которого скорость можно задать до 38400 бод и возможно достичь скорости 45 отсчётов/сек.

В текущем приборе тем же методом на скорости 9600 бод задержки были 150 мсек в среднем. Моя программа на c++ уменьшила это число в три раза, плюс даёт больше возможностей по синхронизации. В предыдущей версии для изменения частоты опроса я менял задержку и это приводило к пропускам (системный буфер у меня сбрасывается каждый раз).

The trick, ты вообще на низком уровне с железом работал когда-нибудь? Ты знаешь назначение таймаутов операций чтения байтов? Через сколько буферов проходит байт прежде, чем он от провода придёт ко мне в программу?

У меня такое чувство, что ты никогда не видел как ведётся отладка программы, которая работает с COM-портом. Вот пример лога, который я снял при работе с прибором в командном режиме на скорости 9600 бод (8-N-1):
Скажи сколько миллисекунд физически длится ответ и почему?

Добавлено через 1 час 32 минуты

Сообщение от The trick Нет, это не будет работать, не нужно дезинформировать людей. Будет работать только когда чтение пройдет внутри ReadFile (вернет не NULL), считай практически никогда; эквивалентно вызову синхронной функции, т.е. эффекта от асинхронности нет никакого. Вот поэтому у тебя и синхронный вызов работает без проблем, а асинхронный не работает.

Будет, не будет. Это смотря какая постановка задачи и что мы имеем практически. Представь, у тебя есть Windows, у которой и запись, и чтение буферизированы. У тебя есть источник посылок, который генерирует их каждые 100 мсек. По ТЗ у конечного пользователя есть только офис с поддержкой макросов. Нужно принять данные и отобразить их графически. Использовать Excel. Есть также источники с протоколом запрос-ответ, желательно иметь минимальные издержки обмена по времени.

Это сильные ограничения, но WinAPI тебе доступен. Далее, ты находишь в сети готовый код, который работает, но не совсем. К примеру, в командном режиме, если ты делаешь так:

1. Сброс буферов записи и чтения Windows.
2. WriteFile
3. ReadFile

то это не работает (программный буфер пустой), а если ты делаешь так:

1. Сброс буферов записи и чтения Windows.
2. WriteFile
3. Sleep(100)
4. ReadFile

то ответ всегда можно считать из приёмного буфера Windows. Можешь с ходу указать в том исходнике почему так?

Вот отсюда все и проблемы. Sleep(100) на самом деле эмпирическая вещь, кроме того есть неучтённые задержки, которые зависят от производительности компа (мы работаем в Excel). Это +/- 20-50 мсек, точно не знаю. А эти задержки на больших скоростях уже сопоставимы с длиной пакетов байт команд. Считать-то мы уже умеем?

Я уж не упоминаю DoEvents, которая там в коде используется для сброса буфера записи в физический порт. Это что-то вообще ненормальное.

Так вот, чтобы понять, почему ReadFile там не ждёт посылки, а сразу возвращает управление, нужно разобраться в инициализации порта, используемом алгоритме и хорошо прочитать MSDN. И совершенно параллельно каким образом тут ReadFile работает с буфером пользователя.

0

Сообщение от уни The trick, ты вообще на низком уровне с железом работал когда-нибудь?

Работал. Собирал несколько устройств на AVR которые обменивались данными с компьютером по UART.

Сообщение от уни Ты знаешь назначение таймаутов операций чтения байтов?

Зависит от скорости, количества бит (данные, стартовый, стоповый, четность и т.д.), интервала между данными и еще от кучи факторов. Рассчитать можно так:

Сообщение от уни Через сколько буферов проходит байт прежде, чем он от провода придёт ко мне в программу?

Как минимум через буфер, задаваемый SetupComm.

Сообщение от уни Скажи сколько миллисекунд физически длится ответ и почему?

При скорости 9600 бод, время передачи 1 байта данных (10 бит в твоем случае) будет составлять ~1042 мкс + интервал между символами (зависит от устройства), умножать на количество байт, в твоем случае 20.

Сообщение от уни Будет, не будет. Это смотря какая постановка задачи и что мы имеем практически. Представь, у тебя есть Windows, у которой и запись, и чтение буферизированы. У тебя есть источник посылок, который генерирует их каждые 100 мсек. По ТЗ у конечного пользователя есть только офис с поддержкой макросов. Нужно принять данные и отобразить их графически. Использовать Excel. Есть также источники с протоколом запрос-ответ, желательно иметь минимальные издержки обмена по времени.

Не вижу связи с проблемой типизации данных в твоем случае. Тип Byte() в Excel'е есть.

Сообщение от уни Так вот, чтобы понять, почему ReadFile там не ждёт посылки, а сразу возвращает управление, нужно разобраться в инициализации порта, используемом алгоритме и хорошо прочитать MSDN. И совершенно параллельно каким образом тут ReadFile работает с буфером пользователя.

Что за бред? Твой вопрос как был поставлен:

Сообщение от уни запрос-ответ происходит (слежу монитором порта), а вот в приёмный буфер данные не записываются, хотя принятое количество байт показывается. Не пойму в чём дело.

Что ты теперь говоришь тут что тебе параллельно каким образом функция работает с буфером? Твоя проблема в том что ты используешь тип String для буфера, и совершенно не понимаешь как это работает. И самое интересное что ты не слушаешь других. Зачем тогда задавать вопрос на форум?
Ты передаешь String по значению - это обозначает автоматическую конвертацию строки из Unicode в Ansi перед вызовом функции, передачи Ansi буфера в функцию и конвертации из Ansi в Unicode буфера при выходе из функции. Это знает любой более-менее разбирающийся программист на VB6. Смотри - у тебя асинхронная запись в буфер, т.е. после выхода из функции данные в буфер будут писаться в него, а у тебя уже этого временного буфера нет (данные пишутся в никуда, хорошо что приложение не вылетает и число прочитанных байт соответствуют истине), а с исходной строкой ничего не происходит, она вообще не участвует в операции. Если ты передашь туда указатель на первый элемент массива - то они будут писаться туда и никуда больше.
И как после такого можно говорить о неважности типа?

0

Молодец, приятно увидеть логичные рассуждения. Этот факт я не учитывал, так как не обратил внимания на ByVal по причине уже работающего кода. Мог бы и раньше сделать такое пояснение, оно не очевидное.

Сообщение от The trick При скорости 9600 бод, время передачи 1 байта данных (10 бит в твоем случае) будет составлять ~104 мкс + интервал между символами (зависит от устройства), умножать на количество байт, в твоем случае 20.

Формула правильная, только на порядок в расчётах ошибся. Прикинь, 9600 бит в сек (бод - baud rate - битовая скорость), 10 бит в символе - 960 символов в сек, округлим - 1000 симв в сек - это 1 мсек на символ. Итого, около 20 мсек на ответ.

0

Сообщение от уни Мог бы и раньше сделать такое пояснение, оно не очевидное.

Я тебе явно написал

Сообщение от The trick у тебя в коде на C++ буфер представляет собой массив из 21 элемента типа char (аналог VB6 - byte)

Сообщение от уни Формула правильная, только на порядок в расчётах ошибся.

Это опечатка, невнимательно проверил пост перед отправкой, там не 104 мкс, ~1042 мкс (10/9600), исправил.

0

Я имел в виду двойную неявную конвертацию String при использовании WinAPI в vb6. Я к этому не привык. Ни за что бы не догадался о таком подводном камне.

На самом деле меня конечно смутило такое обертывание ReadFile, так как мне удобнее было работать с байтами (в примере выше текстовый протокол, есть ещё бинарный), но это строковое представление в коде сильно завязано и мне просто лень было всё переделывать, считай, писать заново.

Добавлено через 13 минут
Чтобы пока сильно не переделывать, попробую совет отсюда тоже:

И с "ByVal s As String" и "ByRef s As String" передается строка ANSI, только в первом случае передается адрес этой строки (char*), а во втором — адрес адреса (char**). Чтобы VB не преобразовывал строки, их нужно передавать через Long: "ByVal s As Long" и передавать StrPtr(s).

Добавлено через 11 часов 20 минут

Чтобы VB не преобразовывал строки, их нужно передавать через Long: "ByVal s As Long" и передавать StrPtr(s).

Это не заработало в моём случае. Тут тоже такой способ советуют.

Замена на байтовый буфер заработала. Признаю свою ошибку и ограниченность знания внутренней кухни vb6 при работе с WinAPI.

0

Получил хорошие результаты с конкретным прибором. Длина команды 4 байта, ответа - 6 байт, скорость - 38400 бод. Получается теоретическое минимальное время между запросами: 10 / 3840 байт/сек ~= 2,6 мс. Практически у меня сейчас получается 180 Гц ~ 5,6 мсек (у меня введена дополнительная задержка между командой и ответом в 1 мсек). Стабильность между запросами пытаюсь поддерживать при помощи QueryPerformanceCounter(), регулируя задержку, которую делаю при помощи Sleep(). Но сам Sleep(), я думаю, не всегда может точно выдержать интервал в несколько мсек, хотя результаты достаточно стабильны: 5-6 мсек между отсчётами.

Зазубрины на графике связаны с ограниченной частотой измерения в самом приборе. Результаты для COM-порта и переходника USB-COM (Moxa) получились практически одинаковыми.

Асинхронный режим работы позволил увеличить частоту опроса с 50 Гц до 180 Гц. Код оформлен в виде макросов для Excel.

Миниатюры

 

0

Почему-бы не использовать буфер для сразу нескольких команд?

0

Прибор этого не понимает. Я пытался скормить ему через монитор порта посылку из нескольких команд, но он ответил только на одну из них, т.е. у него нет буферизации команд.

0

Сообщение от уни Прибор этого не понимает. Я пытался скормить ему через монитор порта посылку из нескольких команд, но он ответил только на одну из них, т.е. у него нет буферизации команд.

Каково время ответа? Забей буфер так с 0 между командами, чтобы было время для обработки.

1

Надо же, это заработало. Мне не пришло такое в голову, спасибо за идею. Я вбил в мониторе 10 байтов нулей между командами (длина ответа 6 байт) и прибор ответил на каждую. Пробовал пока вручную 2 и 3 команды.

0